DataAccess项目中类的命名约定是什么？
我通常将Business项目中的类命名为Manager.cs，如BaseManager.cs，CommentsManager.cs，ProfileManager.cs等…
如何在DataAccess项目中命名您的类？ 你称之为CommentsDA，CommentsDB还是什么？
好奇…… BTW，我正在使用.NET C＃。
软件层之间的命名约定
我过去常常为每种软件层分离类命名约定，就像你要问的那样。 然而，在.NET世界中，实现每个层是它自己的程序集，并且程序集通常可以用实现相同接口的程序集替换，我发现命名空间是最重要/有效的更改，并且删除了类特定的前缀和后缀，在大多数情况下。
例如，我曾经有过Customer （业务）和CustomerDAL （数据访问层）
..在我最近的项目中经常发生变化 ，分别……
ICustomer和ICustomer之间使用了ICustomer接口，而不是直接访问目标项目中的任何特定类。
类命名重要性由低内聚力改变
通常，通过实现类后缀或前缀，您试图防止紧密耦合的程序集之间的命名冲突。
然而，通常建议通过接口 使用松散耦合的组件 ; 副作用是你不再直接使用具体的类名。 否则，通过使用紧耦合组件，您可以将它们组合成一个组件，因为它们直接相互依赖，并且单独组件的好处会减少。
有时候我的软件采用了更具描述性的方法，比如Customer和CustomerData类，我意识到这是使用后缀，但目的是为了自然流，而不是防止命名冲突，因为我的界面无论如何都在它们之间。
简而言之，低内聚性使得在项目的任何层中相对于彼此应该/可能/将被命名的类的问题没有实际意义。 而且因为您已经有了用于业务和数据职责的单独程序集，所以您必须隐含地希望存在低内聚。 因此，根据问题的概念，我在应用程序设计的上下文中的答案是没有类后缀或前缀客观上更好 。
C＃代码示例
为了一个有用的代码示例，我将包含以下C＃框架来显示我所倾向的类命名策略（或者缺少策略可能更准确）。
注意：此示例在某些方面不完整，但显示了类命名在程序集之间无关紧要的概念（即使它是相同的类名），因为它们是使用接口分隔的。
Business.dll – 业务层程序集
引用Shared.dll程序集。
namespace Com.Examle.MyProject.Business { using Com.Example.MyProject.Shared; // for ICustomer class Customer { // Reference obtained to an ICustomer implementation (not shown). // Composition of the data customer, just for illustration purposes ICustomer _cust; // From business, a data access usage example: public void GetData() { _cust.SaveToDataSource(); } } }
业务正在使用ICustomer而不是硬连接到Data.dll程序集。
Shared.dll – 共享程序集 – 公共类型被引用到业务和数据程序集中。
// This is the only required link between business and data assemblies. // Business is shielded from Data concrete class names and vice-versa. namespace Com.Example.MyProject.Shared { public interface ICustomer { void SaveToDataSource(); } }
Data.dll – 数据访问层
引用Shared.dll程序集。
namespace Com.Example.MyProject.Data { using Com.Example.MyProject.Shared; // for ICustomer class Customer : ICustomer { // implement ICustomer - other assemblies can too public void SaveToDataSource() { // logic to save data to the data source } } }