这绝对是主观的,但我想尽量避免它变成争论。我认为如果人们恰当地对待它,这将是一个有趣的问题。

这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上,但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。

那么,你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如,大括号放置),但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。

请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点,不管你是否恰好同意这些观点。


当前回答

我真的不喜欢当人们告诉我使用getter和setter而不是使变量公共时,你应该能够获得和设置类变量。

我完全同意如果是改变对象中的一个变量在你的对象中,你不会得到这样的东西:a.b.c.d.e = something;但我更愿意使用:a.x = something;然后a.setX(东西);我认为a.x =某物;实际上,在同一个例子中,它们都更容易阅读,而且比设置/获取更漂亮。

我不明白为什么要这样做:

void setX(T x) { 这个->x = x; }

T getX () { 返回x; }

这就需要更多的代码,需要更多的时间,你要一遍又一遍地做,这只会让代码更难阅读。

其他回答

规模很重要!修饰你的代码,让它看起来更大。

开发团队应该更多地按照技术/架构层而不是业务功能来划分。

我来自一个开发者拥有“从网页到存储过程的一切”的普遍文化。因此,为了在系统/应用程序中实现一个功能,他们将准备数据库表模式,编写存储procs,匹配数据访问代码,实现业务逻辑和web服务方法,以及web页面接口。

And guess what? Everybody has their own way to doing things! Everyone struggles to learn the ASP.NET AJAX and Telerik or Infragistic suites, Enterprise Library or other productivity and data layer and persistence frameworks, Aspect-oriented frameworks, logging and caching application blocks, DB2 or Oracle percularities. And guess what? Everybody takes heck of a long time to learn how to do things the proper way! Meaning, lots of mistakes in the meantime and plenty of resulting defects and performance bottlenecks! And heck of a longer time to fix them! Across each and every layer! Everybody has a hand in every Visual Studio project. Nobody is specialised to handle and optmise one problem/technology domain. Too many chefs spoil the soup. All the chefs result in some radioactive goo.

Developers may have cross-layer/domain responsibilities, but they should not pretend that they can be masters of all disciplines, and should be limited to only a few. In my experience, when a project is not a small one and utilises lots of technologies, covering more business functions in a single layer is more productive (as well as encouraging more test code test that layer) than covering less business functions spanning the entire architectural stack (which motivates developers to test only via their UI and not test code).

System.Data.DataSet岩石!

在我看来,对于大多数业务应用程序,强类型数据集比自定义DDD对象更好。

推理:我们在自定义对象、LINQ to SQL、实体框架上绞尽脑汁地寻找工作单元,这增加了复杂性。使用一个好的代码生成器来生成数据层,工作单元位于对象集合(DataTable和DataSet)上——这并不神秘。

这个怎么样:

垃圾收集器实际上会损害程序员的工作效率,并使资源泄漏更难发现和修复

请注意,我谈论的是一般的资源,而不仅仅是内存。

远离Celko!!!!

http://www.dbdebunk.com/page/page/857309.htm

我认为使用代理主键比使用“自然”主键更有意义。


@ocdecio: Fabian Pascal给出了(在他的书《数据库管理中的实际问题》的第三章中,引用于你链接的页面的第3点)作为选择键的标准之一,那就是稳定性(它总是存在并且不会改变)。当一个自然键不具有这样的属性时,必须使用一个代理键,原因很明显,您在注释中暗示了这一点。

你不知道他写了什么,你也懒得去检查,否则你会发现你实际上同意他的观点。这里没有什么争议:他说的是“不要教条主义,根据情况调整一般的指导方针,最重要的是,思考,用你的大脑,而不是教条主义/食谱/大师的话”。