我通常将Business项目中的类命名为Manager.cs,如BaseManager.cs,CommentsManager.cs,ProfileManager.cs等......
如何在DataAccess项目中命名您的类?你称之为CommentsDA,CommentsDB还是什么?
好奇......顺便说一下,我正在使用.NET C#。
答案 0 :(得分:14)
我曾经像你所问的那样为每种软件层分离类命名约定。然而,在.NET世界中,实现每个层是它自己的程序集,并且程序集通常可以用实现相同接口的程序集替换,我发现命名空间是最重要/有效的更改,并且删除了类特定的前缀和后缀,在大多数情况下。
例如,我曾经有Customer
(业务)和CustomerDAL
(数据访问层)
..在我最近的项目中经常更改,分别为......
Com.Example.ProjectName.Business.Customer
和Com.Example.ProjectName.Data.Customer
之间使用了ICustomer
接口,而不是直接访问目标项目中的任何特定类。
通常,通过实施类后缀或前缀,您可以尝试防止紧密耦合的程序集之间的命名冲突。
然而,通常建议通过接口来建立松散耦合的程序集;副作用是你不再直接使用具体的类名。否则,通过使用紧耦合组件,您可以将它们组合成一个组件,因为它们直接相互依赖,并且单独组件的好处会减少。
有时我的软件采用更具描述性的方法,如 Customer 和 CustomerData 类,我意识到这是使用后缀,但目的是为了自然流而不是防止命名冲突,因为我的界面无论如何都在它们之间。
简而言之,低内聚性使得在项目的任何层中相对于彼此应该/可能/将要命名的类的问题没有实际意义。并且因为您已经有单独的业务组合和数据责任,你必须隐含地希望存在低凝聚力。因此,根据问题的概念,我在应用程序设计方面的答案是没有类后缀或前缀客观上更好。
为了一个有用的代码示例,我将包含以下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();
}
}
}
Business正在使用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
}
}
}