问题是这样的，LINQ to SQL 并不是真正的 Object Relation Mapper (ORM)，它是一个数据访问层生成器.您可以通过深入手动编辑 XML 文件并使用 SqlMetal 使其成为 ORM 等等，但它的亮点在于 DAL.

The thing is this, LINQ to SQL is not a true Object Relation Mapper (ORM), it is a data access layer generator. You can make it be an ORM by going deep by hand editing XML files and playing with SqlMetal and whatnot, but where it shines is as a DAL.

ORM 背后的想法是这样的.您拥有 SQL 数据库和域对象.为了正确设计数据库，您将做一些逻辑上不会转化为正确设计的对象模型的事情(如规范化)，反之亦然.这称为阻抗失配"，ORM 的作用是以干净、有效和高效的方式处理这种失配.减少痛苦的数据库交互几乎是次要的.

The idea behind an ORM is this. You have your SQL database, and your domain objects. To design a database properly, you are going to do things (like normalization) that logically don't translate into a properly designed object model, and vice-versa. This is called "Impedance Mismatch", the role of an ORM is to deal with that mismatch in a clean, effective, and efficient way. The less painful database interaction is almost a secondary thing.

存储库背后的想法是它封装了应用程序其余部分的所有持久性逻辑和对基础架构的依赖关系.当您的应用程序需要 Customer 对象时，它不应该知道它是来自 SQL Server、MySQL、XML 文件还是 ASP.NET Membership.解耦后，您对持久性故事所做的任何更改都不会影响应用程序的其余部分.

The idea behind a repository is that it encapsulates all persistence logic and dependencies on infrastructure from the rest of your application. When your application needs a Customer object, it shouldn't have to know whether it is coming from SQL Server, MySQL, an XML file, or ASP.NET Membership. Once you have that de-coupling, any changes you make to your persistence story have no effect on the rest of your application.

考虑到这一点，他为什么要这样做就更清楚了.LINQ to SQL 用于生成 DAL，但关于 DAL 唯一应该知道的是存储库，因此对其域对象进行了转换.这样他就可以重构他的域模型而不必担心他的持久性故事，他可以重构他的数据库而不必担心通过他的应用程序产生涟漪效应.他还可以在决定使用什么 ORM 甚至数据存储位置等问题之前开始编写业务逻辑代码.

With that in mind, it gets more clear why he did what he did. LINQ to SQL is used to generate the DAL, but the only thing that should be known about the DAL is the repository, so a translation is made to his domain objects. That way he can refactor his domain model without worrying about his persistence story, and he can refactor his database without worrying about rippling effects through his application. He could also start coding on business logic before deciding on questions like what ORM to use, or even where to store his data.

如果他要使用真正的 ORM(例如 NHibernate)，则该映射代码会得到处理其他地方(在 XML 或引导类中).我认为 LINQ to SQL(和 Robs 开源 DAL，SubSonic)是很棒的项目，但更多地是为较小的两层应用程序设计的，在这些应用程序中，诸如存储库模式之类的东西太过分了.店面也很好地说明了为什么 NHibernate 的额外复杂性很重要.他本可以通过使用一些专为处理这种情况而设计的东西来为自己节省大量代码，而不是手动完成所有工作.

If he were to use a real ORM (like NHibernate), that mapping code gets handled elsewhere (either in XML or bootstrapping classes). I think LINQ to SQL (and Robs open source DAL, SubSonic) are great projects, but more designed for smaller, two-tier applications where something like the repository pattern is overkill. The storefront is also a good illustration of why the additional complexity of NHibernate can be important. He could have saved himself a lot of code by going with something built to handle that sort of scenario, rather than doing it all manually.