模型驱动架构是否与 LINQ-to-SQL 或实体框架配合得很好？答案

【问题标题】：Does Model Driven Architecture play nice with LINQ-to-SQL or Entity Framework?模型驱动架构是否与 LINQ-to-SQL 或实体框架配合得很好？
【发布时间】：2010-01-27 14:17:33
【问题描述】：

我新创建的系统是使用模型驱动架构方法创建的，所以我只有模型（假设是综合的“订单”和“产品”类）。这些是支持我的应用程序业务的经过全面测试的类。现在是时候将这些类作为对象保存在硬盘上，并在稍后以相同的状态检索它们（在这里非常抽象地思考）。通常，我会创建一个 IOrderRepository 接口，并最终创建一个 ADO.NET 驱动的 OrderRepository 类，其中包含 GetAll()、GetById()、Save() 等方法……或者在某个时候提供一个 BinaryFormatter 驱动的 OrderRepostiroy 类通过相同的通用接口实现类似的目的。

这种方法是否不利于 LINQ-To-Sql 或实体框架。试图从预先存在的数据库结构构建我的模型的东西似乎是错误的。我能否在利用这些技术的同时保留这种“MDA”软件工程方法？

...请注意，我没有提到这是一个 Web 应用程序。它可能是也可能不是——而且应该不重要。

【问题讨论】：

标签： linq-to-sql entity-framework domain-driven-design

【解决方案1】：

一般来说，我认为您不应该将实现业务方法的类型和用于 O/R 映射的类型设为同一类型。我认为这违反了单一责任原则。您的实体类型的重点是弥合关系空间和对象空间之间的差距。您的业务类型的重点是拥有可测试行为的集合。相反，我建议您在从数据库中具体化对象时，将实体类型投影到业务类型上。将这两者分开可以让您的业务方法和数据映射独立发展，这一点非常重要，尤其是在您无法始终控制数据库架构的情况下。我更全面地解释了这个想法in this presentation。

【讨论】：