ASP.NET MVC2数据访问层

Question

对于中小型项目，我试图找出拥有域层和数据访问层的“理想”方式。我对耦合的看法往往更倾向于认为域模型不应该与数据库层紧密耦合，换句话说，数据访问层实际上不应该知道关于域对象的任何事情。

我一直在关注Linq-to-sql，它想要使用它自己创建的模型，因此最终非常紧密耦合。虽然我喜欢你在代码中使用linq-to-sql的方式，但我真的不喜欢它想要创建自己的域对象的方式。

我应该考虑哪些替代方案？我尝试使用NHibernate，但我不喜欢我用来查询和获取不同对象的方式。老实说，我喜欢你使用linq的语法和方式，我只是不希望它与域对象紧密耦合。

Answer 1

如果您不希望您的域与您的数据库紧密耦合，那么您的选择非常多：

1. NHibernate的
2. 实体框架

您发现的Linq 2 Sql会从您的数据库层生成代码，因此这是不可能的。对于Subsonic和LLBLGen Pro也是如此（我相信，如果我错了，请纠正我）。实体框架也曾落入这艘船，但版本4已经附带“代码优先”支持，所以它绝对是一个选项。

NHibernate和Entity Framework都支持LINQ查询，尽管Entity Framework的LINQ支持应该优于NHibernate的支持。我同意HQL和Criteria查询并不像LINQ那样优雅，但我有一种感觉NHibernate的LINQ支持将在版本3.0中得到极大改进。

Answer 2

我发布了一个可能有帮助的类似问题的答案。我可以在这里重复一遍，但我想我会指出你的答案，因为我会建议使用相同类型的存储库模式来解耦你的数据。

MVC + Repository Pattern - Still depends on Data Model?

Answer 3

您可以使用LINQ to SQL创建表示数据实体的类型。这几乎只是表示数据库中表的类。在MVC项目中，您应该使用这些来向Business层提供数据，您可以从中开始定义Business实体，然后（在我看来，非常重要的是）定义您的Presentation Model。

Answer 4

我知道你并不喜欢NHibernate，但是如果你想再看看它，请查看http://sharparchitecture.net/。在正确分离问题的同时，他们在布置项目模板方面做得非常出色。