将应用程序代码(App_Code)分成单独的文件应该遵循哪些通用准则?随着命名空间层次结构的演变,我发现难以与原始文件相匹配。如何使应用程序代码容器在时间上保持直观组织?文件的分割应该达到什么目的?是代码可移植性?还是关注点分离?还是一般的功能上下文?还是频繁更改的频率?它们应该力争实现类的一对一关系吗?将代码分割成许多小文件与合并成少量文件有什么影响?我经常思考这个问题,但从未达到适用于所有情况的一般结论。
MyAwesomeTool
就足够了,但是对于许多类的较大项目来说,需要更合理的分组。像SDK或.NET BCL这样的大型项目依靠命名空间来分解否则会让人感到压倒性的大量类型。每个命名空间级别提供了有关可能在其中找到的内容的其他信息,例如System.Windows.Forms
或System.Drawing
或Microsoft.VisualBasic
。创建命名空间时,必须考虑该命名空间及相关项目的目的。如果项目是内部小型项目,则可以自己随意命名命名空间,因为它只是将类型分组的必要性;如果项目对外可见或包含大量类型,则应仔细考虑逻辑和有意义的分组方式,以便使他人能够直观地找到他们所需的类型。类和源文件之间应该存在一对一的映射关系。
命名空间应该被视为一个可以包含一个或多个类的包。如果可能的话,将其表示为Visual Studio项目窗口中的文件夹/筛选器可能是有用的。
如果您发现一个庞大的类会受益于拆分成单独的文件,则应考虑重构和拆分类本身,而不是拆分文件。
唯一的(可接受的)例外是生成UI的代码,Visual Studio 将其放在一个单独的文件中。我建议将其保留在自己的文件中,并尽可能地将其视为透明的编辑器所有文件。
大多数建议都是让每个公共类型都应该放在自己的文件中,而命名空间则应该代表应用程序的文件夹结构。
我通常会将99%的1对1类放在一个文件中。唯一的例外是如果您有大量或非常简单的小类,这些类都实现相同的接口并且不应该经常更改。您可能希望将它们放在一个文件中。自定义异常可以作为一个很好的例子。大多数情况下(根据我的经验),除了创建自定义消息或类似的内容之外,没有其他代码。
命名空间应该首先按照关注点分离进行组织。例如,数据对象应该与域对象位于不同的命名空间中。然后,您可以在“聚合根”级别为每个对象组拥有一个较小的子域。通常,这些最小的命名空间对应其自己的项目和DLL。
MyAwesomeApp.UI
MyAwesomeApp.Business
MyAwesomeApp.Data
为了反映层之间的分离。