灵活性与可靠性 [英] Flexibility vs Reliability
问题描述
我的同事和我正在讨论灵活性与可靠性。
例如，这种方法非常灵活：
公共共享函数GetList（ByVal whereClause As String）As String
strSQL =" SELECT field1，field2，field3，field4，field5 FROM table1"
if whereClause<> String.Empty然后
strSQL& =" WHERE" &安培; whereClause
结束如果
返回strSQL
结束功能
我的同事批评它是灵活的，但更喜欢使用更多
可靠的技术，如重载和强类型参数。
公共共享函数GetList（ByVal field1Value As String，ByVal
field2Value As Integer）As String
strSQL =" SELECT field1，field2，field3，field4，field5 FROM table1"
strSQL& =" WHERE field1 =''" &安培; field1Value& "''AND field2 =" &
field2Value
返回strSQL
结束函数
我的论点是你可以'不能预测每个可能的字段
值和参数的组合，所以where子句和重载方法的数量将会增加到荒谬的比例。
让其他人遇到这个问题吗？如果是这样你怎么看待它？
欣赏任何见解和经验。
谢谢！
- -
Joe Fallon
My co-worker and I are debating Flexibility vs. Reliability.
For example this method is highly flexible:
Public Shared Function GetList(ByVal whereClause As String) As String
strSQL = "SELECT field1,field2,field3,field4,field5 FROM table1 "
If whereClause <> String.Empty Then
strSQL &= "WHERE " & whereClause
End If
Return strSQL
End Function
My co-worker agress that it is flexible but would prefer to use more
reliable techniques like Overloading and Strong Typing of parameters.
Public Shared Function GetList(ByVal field1Value As String, ByVal
field2Value As Integer) As String
strSQL = "SELECT field1,field2,field3,field4,field5 FROM table1 "
strSQL &= "WHERE field1=''" & field1Value & "'' AND field2=" &
field2Value
Return strSQL
End Function
My argument is that you can''t predict every possible combination of field
values and arguments so the number of where clauses and overloaded methods
would grow to ridiculous proportions.
Have other people faced this issue? If so what did you think about it?
Appreciate any insights and experiences.
Thanks!
--
Joe Fallon
推荐答案
你好乔，
我想要添加可维护性和实用性（包括可记忆性）
。现在我们有了一个四维空间。在整个
竞技场的实践中，我想你会发现大多数情况都聚集在同一个小的
区域（在整个空间中判断）。放大你也许会发现一些
的整体模式，但实际上，每个案例都必须根据它自己的优点来确定它的位置。
这些品质中的每一个都是主观的。还有一点是，另外一个额外的过量提示乔的规模，但理查德可以愉快地增加两个。
两者都不对。下个月，当Martin加入这个项目时，他必须学习
完整的重载列表或无所不包的
参数的限制。
你真的使用table1和field1，field2等。这是一个更好的区域
我想到的改进。 ;-)
但是，如果你正在寻找个人意见，我会追求最大的灵活性
公共共享函数GetList（ByVal strSQL As String）As String
返回strSQL
结束函数
SCNR; - ）
问候，
Fergus
Hi Joe,
I''d want to add maintainability and utility (which includes memorability)
to the mix. Now we have a four-dimensional space. In practice in that whole
arena, I imagine that you''d find most cases clustered around the same little
area (as judged over the whole space). Zooming in you''d perhaps discover some
overall patterns, but really, each case has to be given its position based on
its own merits.
Each of these qualities is subjective. There comes a point where one more
overload tips the scale for Joe, but Richard could happily add two more.
Neither are right. Next month, when Martin joins the project, he has to learn
either the complete list of overloads or the limits of the all-encompassing
parameter.
Are you really using table1 and field1, field2, etc. That''s a better area
for improvemnt I would have thought. ;-)
But if you''re looking for personal opinions, I''d go for maximum
flexibility
Public Shared Function GetList (ByVal strSQL As String) As String
Return strSQL
End Function
SCNR ;-)
Regards,
Fergus
" Joe Fallon" < JF ****** @ nospamtwcny.rr.com>写了...
"Joe Fallon" <jf******@nospamtwcny.rr.com> wrote...
我的同事和我正在讨论灵活性与可靠性。
你好Joe：我认为我们可以在
新闻组中进行这些类型的讨论，这很好。
我的论点是你无法预测字段值和参数的每种可能组合，所以where子句和重载方法的数量会增长到荒谬的比例。
My co-worker and I are debating Flexibility vs. Reliability.
Hi Joe: I think it''s nice when we can have these types of discussions in a
newsgroup.
My argument is that you can''t predict every possible combination of field
values and arguments so the number of where clauses and overloaded methods
would grow to ridiculous proportions.
选择其中一个的标准之一是谁有权获得
it这意味着如果UI开发人员使用GetList（），那么你的第一个例子
就可以了，并且公平地相信UI开发者会传递一个合法的字符串或者
遭受后果。如果用户的输入将用于提供
where子句，那么你应该考虑更严格的控制。
另一个衡量标准是有没有有什么问题吗？意思是......我们应该怎么样？b $ b过分关注一个愚蠢的条款，当条款从未发生过b $ b时发生了？如果您的灵活实施每天都失败，导致混乱和
中断，那么确定现在是时候解析dang字符串并添加一个你确定是？对话框或重新分配这样做的人。
你想要支持LIKE和>，> =，<和< =所以
组合继续增长......更不用说OR，BETWEEN和
某些条件的括号分组。
如果我想控制一些东西，我也不认为我会超载这个方法
a更多。我可能会将这些方法命名为与各种版本所做的相关的事情，即GetListWhereName（），GetListWhereId（），
GetListWhereState（）或其他什么。他们可能会提供一个通用的GetList，但是如果你试图重载GetList（），那么在你完成之前，你将会耗尽长的
的独特签名。
汤姆
One of the criteria for choosing one over the other is "who has access to
it" meaning if GetList() is used by the UI developer then your first example
is fine and it is fair to trust the UI developer will pass a legal string or
suffer the consequences. If a user''s input would be used to supply the
where clause however then you should consider stricter control.
Another measure is "have there been any problems?" Meaning... should we be
overly concerned about a goofy where clause being passed when it has never
happened? If your flexible implementation fails every day causing chaos and
disruption then "sure" it''s time to parse the dang string and add an "are
you sure?" dialog box or reassign the person doing it.
You would want to support "LIKE" and >, >=, < and <= also so the
combinations continue to grow... not to mention OR, BETWEEN and the
parenthetical grouping of some conditions.
I also don''t think I would overload the method if I wanted to control things
a bit more. I''d probably name the methods something related to what the
various versions did, i.e. GetListWhereName(), GetListWhereId(),
GetListWhereState() or whatever. They might feed a generic GetList but if
you try to overload GetList() you will run out of unique signatures long
before you are even close to done.
Tom
Joe，
我会选择你的第一个例子，但我会重载GetList，而不是检查String.Empty的
。
Joe,
I would go for your first example, However I would overload GetList, instead
of checking for String.Empty.
Const strSQL As String =" SELECT field1，field2，field3，field4，field5
FROM table1"
公共共享函数GetList（ByVal whereClause As String）As String
返回strSQL& "在哪里 &安培; whereClause结束函数
公共共享函数GetList（）As String
返回strSQL
结束函数
请注意，带字符串的第一个重载假定你有一个
正确形成where子句，其中第二个是''all''的情况。
而不是尝试你的第二个函数，主要是同样的原因你
州。如果我想要这个灵活性，我会建议实现一个查询
对象模式。
http://www.martinfowler.com/eaaCatalog/queryObject.html
这将允许更大的灵活性。
查询对象模式来自Martin Fowler的企业模式/
应用程序架构。来自Addison Wesley
http：//www.martinfowler .com / books.html＃eaa
查询对象的简化形式是让你的第二个函数
接受一个ParamArray Criteria对象，其中每个Criteria对象都有一个
字段，一个比较运算符和一个值。
类似（不完整，未经测试）的东西：
''您可以使用字符串而不是定义枚举。
公共枚举运算符
无
等于
NotEqual
GreaterThen
结束枚举
公共类标准
private m_field作为字符串
private m_operator作为运算符
private m_value As String
Public Sub New（字段为字符串，运算符为运算符，值为
整数）
Public Sub New（字段为字符串，运算符为运算符，值为
Double）
Public Sub New（字段为字符串，运算符为运算符，值为
字符串）
...
公共覆盖函数ToString（）As String
结束类
公共共享函数GetList（ByVal ParamArray标准（）作为标准）
As String
Dim sb As New StringBuilder（" SELECT * FROM WHEREVER"）
if criterias.Length> 0然后
sb.Append（WHERE）
结束如果
对于每个标准作为标准在标准中
sb.Append（标准）''使用重载的ToString函数
sb.Append（" AND"）
下一页
如果标准.Length> 0然后
sb.Length - = 5''删除尾随AND
结束如果
返回sb.ToString（）
结束功能
然后当你打电话给它时，你会使用：
GetList（New Criteria（" Field1"）， Operator.Equal，1），New
Criteria（" Field2"，Operator.NotEqual，2））
这个简化的查询对象的优点是Criteria的超载
构造函数可以处理引用和&正确地转换价值。
虽然您已经共享了GetList，但我发现在对象上可以覆盖的价值更高。
。如果你有Table Data Gateway对象，那么对于每个表中自己的对象的'SQL''，这个对象有可覆盖的
方法来获取&调用那些方法。第一个&第三种方法比第二种方法更好地支持
多态性。问题当然是你露出字段名称，马丁的书中也有关于如何减轻这种情况的想法。
http://www.martinfowler.com/eaaCatal...taGateway.html
希望这有帮助
Jay
" Joe Fallon" < JF ****** @ nospamtwcny.rr.com>在消息中写道
新闻：％2 **************** @ TK2MSFTNGP12.phx.gbl ...我的同事和我正在辩论灵活性vs可靠性。
例如，这种方法非常灵活：公共共享函数GetList（ByVal whereClause As String）As String
strSQL =" SELECT field1，field2，field3， field4，field5 FROM table1"
if whereClause<> String.Empty然后
strSQL& =" WHERE" &安培; whereClause
结束如果
返回strSQL
结束功能
我的同事说它很灵活，但更喜欢使用更多可靠的技术，如重载和强大的参数类型。
公共共享函数GetList（ByVal field1Value As String，ByVal
field2Value As Integer）As String
strSQL =" SELECT field1，field2，field3， field4，field5 FROM table1"
strSQL& =" WHERE field1 =''" &安培; field1Value& "''AND field2 =" &
field2Value
返回strSQL
结束函数
我的论点是你不能预测每个可能的字段值和参数的组合所以条款和重载方法的数量会增加到荒谬的比例。
让其他人遇到这个问题吗？如果是这样你怎么看待它？
欣赏任何见解和经验。
谢谢！
-
Joe Fallon
Const strSQL As String = "SELECT field1,field2,field3,field4,field5 FROM table1"
Public Shared Function GetList(ByVal whereClause As String) As String Return strSQL & " WHERE " & whereClause End Function Public Shared Function GetList() As String
Return strSQL
End Function
Notice that the first overload with a string assumes that you have a
properly formed where clause, where as the second is the ''all'' case.
Rather then attempt your second function, for largely the same reasons you
state. If I wanted this flexibity I would recommend implementing a Query
Object pattern.
http://www.martinfowler.com/eaaCatalog/queryObject.html
Which will allow significantly more flexibity.
The Query Object Pattern is from Martin Fowler''s "Patterns of Enterprise
Application Architecture" from Addison Wesley
http://www.martinfowler.com/books.html#eaa
A simplified form of the Query Object would be to have your second function
accept an ParamArray of Criteria objects, where each Criteria object has a
field, a comparison operator and a value.
Something like (incomplete, untested):
'' You could just use a string instead of defining the Enum.
Public Enum Operator
None
Equal
NotEqual
GreaterThen
End Enum
Public Class Criteria
private m_field As String
private m_operator As Operator
private m_value As String
Public Sub New(field As String, operator As Operator, value As
Integer)
Public Sub New(field As String, operator As Operator, value As
Double)
Public Sub New(field As String, operator As Operator, value As
String)
...
Public Overrides Function ToString() As String
End Class
Public Shared Function GetList(ByVal ParamArray criterias() as Criteria)
As String
Dim sb As New StringBuilder("SELECT * FROM WHEREVER ")
if criterias.Length > 0 then
sb.Append(" WHERE ")
End If
For Each criteria As Criteria In criterias
sb.Append(criteria) '' uses the overloaded ToString function
sb.Append(" AND ")
Next
if criterias.Length > 0 Then
sb.Length -= 5 '' remove the trailing AND
End If
Return sb.ToString()
End Function
Then when you call it, you would use:
GetList(New Criteria("Field1", Operator.Equal, 1), New
Criteria("Field2", Operator.NotEqual, 2))
The advantage of this simplified Query Object is that Criteria''s overloaded
constructors can handle quoting & converting the value correctly.
Although you made the GetList shared, I see more value in it being
overridable on an object. Where you have Table Data Gateway objects, where
the ''SQL'' for each table in its own object, this object have overridable
methods to get & invoke those methods. The first & third methods support
polymorphism better then the second. The problem of course is you are
exposing field names, Martin''s book has ideas on how to mitigate that also.
http://www.martinfowler.com/eaaCatal...taGateway.html
Hope this helps
Jay
"Joe Fallon" <jf******@nospamtwcny.rr.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... My co-worker and I are debating Flexibility vs. Reliability.
For example this method is highly flexible:
Public Shared Function GetList(ByVal whereClause As String) As String
strSQL = "SELECT field1,field2,field3,field4,field5 FROM table1 "
If whereClause <> String.Empty Then
strSQL &= "WHERE " & whereClause
End If
Return strSQL
End Function
My co-worker agress that it is flexible but would prefer to use more
reliable techniques like Overloading and Strong Typing of parameters.
Public Shared Function GetList(ByVal field1Value As String, ByVal
field2Value As Integer) As String
strSQL = "SELECT field1,field2,field3,field4,field5 FROM table1 "
strSQL &= "WHERE field1=''" & field1Value & "'' AND field2=" &
field2Value
Return strSQL
End Function
My argument is that you can''t predict every possible combination of field
values and arguments so the number of where clauses and overloaded methods
would grow to ridiculous proportions.
Have other people faced this issue? If so what did you think about it?
Appreciate any insights and experiences.
Thanks!
--
Joe Fallon
这篇关于灵活性与可靠性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
