我们正在讨论为工作定义实体类方法的最佳方法 - 作为扩展方法或使用部分类.我们谈论的那种方法不会修改实体的状态,它们纯粹是"帮助"方法,它们询问状态并返回一个值.
这两种方法的主要好处是保持实体类清洁,同时仍然为客户端代码提供intellisense支持.
无论是哪种方式,我都没有强烈的偏好,但我很想知道其他人是否对某一方有偏好(或知道有记录的指导方针).
我开始编写我能想到的每种方法的优点列表,但最后我想出的是:
部分类
方法定义位于类中(即使它是另一个文件),因此Visual Studio工具支持"查找方法"(例如,resharper中的ALT- \)将定位方法
一旦由于使用partial关键字打开实体类,包含辅助方法的其他文件的存在就很明显
扩展方法
文件的命名("entityNameExtension")及其在项目中的位置(在"Extensions"子文件夹中)直观且易于搜索
其他人可以加入他们的意见吗?
PS我不认为这是以下问题的重复,因为该问题的提问者满足于标记一个响应,该响应将功能差异概述为正确答案,而不回答关于哪种方法是最佳实践的问题在这种情况下: 部分类与扩展方法
编辑 - 我正在寻求人们对一种方法或另一种方法的偏好,因为我们无法找到针对此特定方案的文档指南.这两种方法都是可能的,既不违反任何设计原则,所以这是一个偏好的问题,我想知道你的.
在我看来,扩展方法适用于两件事.首先,当您将它们应用于接口时,它会让您产生编写抽象基类的错觉,该基类允许您定义一些常用方法,但它更灵活,因为类只能有一个基类但可以实现多个接口.其次,如果你将它应用于常规课程,那么我倾向于将其视为某种黑客攻击.当原始类缺少某些方法时,你真的觉得他们应该有这些方法,但他们没有,并且它们超出你的范围,所以你被迫在其他地方实现它们,作为实用方法,它给出了你有一种错觉,它实际上就在那里.
这两种情况最终都只是语法糖,但扩展接口对我来说更有意义,例如我只看LINQ的Enumerable类.我已经在几十个完全不同的类上使用了这些扩展方法,所以它确实得到了回报.类扩展方法的一个例子是在我将自己的string.IsNullOrWhitespace添加到框架之前.
扩展接口似乎是正确的,因为接口定义了一个契约,并且您可以在扩展方法中依赖该契约,但是当您扩展常规类时,它可能会更改并破坏您的扩展方法.当然,界面也可能会改变,但我认为它们往往设计得更彻底,但我没有任何统计数据.
然后就是面向对象编程的情况.你觉得你的方法应该去哪里,谁使用那些额外的方法,边界在哪里.如果您认为某个方法属于某个类,则将其放在类中.这很有道理,很简单.哈哈,人们在推广扩展方法之前写了非常好的课程,把所有内容都放在了所属的地方,生活也很好.
部分类很酷,因为它们不像扩展方法那样大.它们不是语法糖,不是魔术.它只是处理自动生成的类的最好和最简单的方法,所以我不会想太多.我编写了一些代码生成器,它们会发出人们可以编写自己的东西的区域,并且在后续的代码生成中不会被覆盖.这样更舒服,但就是这样.我不能改变.NET工具生成代码的方式,也不会这样做,所以部分类是下一个最好的东西.
总而言之,我的意见是只在必要时才使用扩展方法,并尽可能使用部分类.