程序集上的 NDepend 指标
您是否尝试将每次装配的与主序列的距离保持在较低水平？ 只包含业务对象定义的程序集又如何呢？ 是否有可能让他们远离疼痛区？ 此类程序集中的类型通常由其他程序集使用，并且相当具体。 遇到这样的情况该如何处理呢？
Do you try to keep the Distance from main sequence low for every assembly? What about assemblies that contains only Business Objects definitions? Is it possible to keep them away from Zone of Pain? Types in such assemblies are usually used by other assemblies and are rather concrete. How to handle such situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我相信{保持“与主序列的距离”较低}的目标是基于德米特法则< /a>. 遵循此规则有助于使您的代码更易于理解并且更易于进行单元测试。 通过使用仅作为数据容器的业务对象，您将暴露比可能需要的更多的状态，并且破坏了封装规则。
然而，正如 Fowler 在本文中指出的那样，“虽然方法链有异味，相反，中间人对象因转发方法而臃肿也是一种味道（我一直觉得如果将德墨忒尔法则称为德墨忒尔建议，我会更舒服。）”
我认为这种价值。如果您只想传递对象包含的“内容”，例如它们如何用作数据传输对象，则基本业务对象可能很有用。 然而，区分真正的业务对象和空的数据传输对象可能很重要。 我认为真正的业务对象还应该包含行为以及它们封装的数据。
I believe the objective of {keeping the "distance from main sequence" low} is based on the Law of Demeter. Following this rule helps make your code easier to understand and easier to unit test. By using Business Objects that are mere data containers, you are exposing more state than may be necessary and breaking rules of encapsulation.
However, as Fowler points out in this article, "While method chains are a smell, the opposite problem of middle men objects bloated with forwarding methods is also a smell. (I've always felt I'd be more comfortable with the Law of Demeter if it were called the Suggestion of Demeter.)"
I think the value of such basic Business Objects can be useful if you only want to pass around "what" the object contains, such as how they are used as Data Transfer Objects. However, it's probably important to distiguish your true Business Objects from your empty Data Transfer Objects. I would assume real Business Objects should also contain behavior along with the data they encapsulate.