我正在努力提高我的设计模式技巧,我很好奇这些模式之间有什么区别？所有这些看起来都是一样的 - 封装了特定实体的数据库逻辑,因此调用代码不了解底层持久层.从我的简短研究中,他们通常都会实现您的标准CRUD方法并抽象出特定于数据库的详细信息.
除了命名约定(例如CustomerMapper与CustomerDAO vs. CustomerGateway vs. CustomerRepository)之外,有什么区别？如果存在差异,您何时会选择一个而不是另一个？
在过去,我会编写类似于以下的代码(简化,自然 - 我通常不会使用公共属性):
public class Customer
{
public long ID;
public string FirstName;
public string LastName;
public string CompanyName;
}
public interface ICustomerGateway
{
IList<Customer> GetAll();
Customer GetCustomerByID(long id);
bool AddNewCustomer(Customer customer);
bool UpdateCustomer(Customer customer);
bool DeleteCustomer(long id);
}
并有一个CustomerGateway类为所有方法实现特定的数据库逻辑.有时我不会使用接口并使CustomerGateway上的所有方法都是静态的(我知道,我知道,这使得它不太可测试)所以我可以这样称呼它:
Customer cust = CustomerGateway.GetCustomerByID(42);
这似乎与Data Mapper和Repository模式的原理相同; DAO模式(与Gateway相同,我认为？)似乎也鼓励特定于数据库的网关.
我错过了什么吗？有3-4种不同的方式做同样的事情似乎有点奇怪.
我是DDD + TDD世界的新手.但我已经编程了将近9年.
有人可以解释我坚持不懈的好处吗？典型的nHibernate应用程序只是将类和数据库之间的依赖关系推送到映射文件.
如果我更改类文件或数据库,我必须更改映射文件.那么是不是只是通过添加一个抽象层来推动依赖？在我看来,到目前为止,我认为这不是革命性的.但我不确定我是否遗漏了什么.
最后,我如何测试映射文件？映射文件中可能会出现错误,我该如何测试它们？
持久性无知通常被定义为持久化和检索标准.NET对象的能力(如果您真的坚持给它们命名,则为POCO).一个看似公认的标准.NET对象定义是:
"...普通的课程,你专注于手头的业务问题而不添加与基础设施相关的原因......"
但是,我看到人们将NHibernate描述为一个允许持久性无知的框架,但它是一个不能在任何标准.NET对象上工作的框架,只有符合特定设计要求的标准.NET对象,例如(源代码):
(旁白:在任何人不高兴之前,我并不打算在这里选择NHibernate,它只是一个经常被引用的框架示例,据说允许持久性无知.我敢肯定类似的论点可以应用于其他声称相同的ORM .)
现在虽然这个类本身没有任何持久性特定于框架的属性或基类等,但对我而言,它实际上并不是"持久性无知",因为它必须遵循一套设计指南以便于所选持久性框架的使用.您必须考虑到持久性框架的要求来设计和实现该类; 如果你不了解它,那么这个班可能无法使用它.
当我在与"持久性无知" /"POCO"的定义问题是,我不知道怎么样,从概念上讲,这是真的有什么不同,以添加属性,如[Serializable]或[DataContract]或[XmlType]或任何其他持久性框架,具体的注解这有利于使用该框架的实体的持久性和检索.
那么,"持久性无知"到底是什么？
很明显,将它定义为能够持久化"普通类"是一种谬误,因为NHibernate只是在没有引用特定于框架的类的情况下是普通的,而它们非常特殊,因为它们需要不寻常的设计选择,例如默认构造函数和所有类-virtual成员和可变类型的Equals/GetHashCode实现.
因此,当对象促进使用持久性框架(在设计和结构中或通过使用特定于框架的注释)但不执行任何持久性逻辑时,"持久性无知"是否合理？