将应用程序代码(App_Code)划分为单独文件的一般准则/陷阱应该是什么？
我发现,随着时间的推移,原始文件与命名空间层次结构的演变方式不匹配.如何随着时间的推移直观地组织应用程序代码容器？
档案部门的目标应该是什么？代码可移植性？关注点分离？一般功能背景？变化的频率？他们应该努力与班级建立1-1关系吗？
将代码拆分为多个较小的文件与合并为少量文件有什么影响？
我经常想到这一点,但从未真正达成适用于所有情况的任何一般性结论.
这个问题的答案并不是绝对的,因为它通常取决于你手头的任务.如果您正在创建某种SDK以供其他人重用,那么名称空间非常重要; 但是,如果您只使用几个类创建内部工具,则命名空间几乎不重要.
一般来说,类应该有自己的文件,因为这简化了人们浏览代码解决方案的方式,有助于开发和维护(例如,当每个人都在更改相同的文件时合并更改会更加困难).在某些情况下,将一个类拆分为多个文件是可以接受的,例如:
当存在嵌套类时,每个嵌套类都可以拥有自己的文件.
当类中有自动生成的部分时,如设计器代码.
当类中有固定部分时,例如一组常见的隐藏属性或接口的常见实现.
在我们的一个项目中,我们有一个许多类公开的接口的通用实现.由于我们没有多重继承,我们采用混合方法,我们为每个类自动生成一个额外的文件.这可以手动完成,而不是自动完成(原来是).
还有其他情况,但这有点主观,取决于您自己的项目的要求.
命名空间通常应该关注类型的合理分组.命名空间应该允许开发人员直观地找到他们正在寻找的内容.对于许多小项目,单个命名空间MyAwesomeTool就足够了,但是对于具有许多类的大型项目,则需要更合理的分组.像SDK或.NET BCL这样的大型项目依赖命名空间来分解大量的类型.每个命名空间级别提供什么可能在那里发现,如额外的信息System.Windows.Forms或System.Drawing或Microsoft.VisualBasic.
在创建名称空间时,必须考虑到该名称空间和相关项目的目的.如果项目是内部的和小的,请调用命名空间你喜欢的,因为它只是分类你的类型的必要条件; 如果项目在外部可见或包含大量类型,请仔细考虑逻辑和有意义的分组,以便其他人能够直观地找到他们正在寻找的类型.
在任何情况下都没有严格的规则.如何将代码安排到文件中与您自己的开发过程相关,影响您和您的团队; 你在一个文件中的所有类都将开发,但编译后的产品不会有任何不同(假设一种文件方法没有导致错误),而你的命名空间的安排与未来的发展和消费者有关.那些名称空间,所以错误的后果可能更严重.
旨在以简化当前开发和未来维护的方式组织您的课程.
旨在以简化所有开发的方式组织您的命名空间,并在适当的情况下简化最终用户的体验.
类和源文件之间应该存在一对一的映射.
命名空间应该被视为可以包含一个或多个类的包.在可能的情况下,在Visual Studio项目窗口中将这些表示为文件夹/过滤器可能很有用.
如果你发现一个相当大的类,你觉得将被分成单独的文件,然后考虑重构和拆分类本身.
(可接受的)例外是生成Visual Studio放在单独文件中的UI的代码.我建议将其保留在自己的文件中,并尽可能将其视为透明的编辑器拥有的文件.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
