SubSonic 3，用于ASP.NET MVC开发的实体数据模型（实体框架）或LINQ to SQL？

Question

在使用了所有这些功能（比其他功能更多）之后，我仍然不确定哪种才是最好的使用方式（.NET 3.5）。 在开发时，每个优点和缺点是什么？

亚音速3
没有足够的示例/文档（我知道它是一个Wiki，人们可以对其进行更新，但是要追踪到这些信息可能很棘手-例如示例应用程序在哪里（WebForms，MVC（当前版本，而不是3版之前的版本），WinForms） ）。 第一次尝试时，文本模板未按预期工作。 例如，它不会像SubSonic 2那样清理表名（例如，删除/替换空格）。 另外，您不能说要包括哪些表，而不能说出要排除的表（在ActiveRecord.tt ）。 Context.tt和Structs.tt为所有表生成代码（您可能不希望使用“ aspnet_”表，也可能不希望使用某些其他表（会话表））。

虽然这样说（希望我不太苛刻），但使用它是一个很好的ORM，除了小问题。

实体数据模型（实体框架）
用于设置模型的Visual Designer。 与数据库同步可能被认为有点“冗长”并且难以理解。 虽然有相当不错的文档。 虽然没有深入。

LINQ to SQL还具有用于创建模型的设计器。 易于使用。 功能少于其他两个。 我还必须为一个不起眼的错误应用修补程序（当模型具有非int类型的外键时，将不会更新）

NHibernate
过去看过这个，但与上面相比设置起来并不容易。 是否有任何使用此示例的ASP.NET MVC应用程序？

理想情况下，我需要一个框架：

a）可以从数据库生成模型
b）支持LINQ语法
c）仅检索所需的数据（例如，用于分页）
d）允许数据注释
e）可以生成sql以在现有数据库中更新或创建新表

Answer 1

MVC是表示层，ORM是数据层

我认为ORM与MVC应用程序 没有 太大关系。 至少如果您正确地对应用程序进行分层。 MVC应用程序中的模型是表示层视图的模型。 控制器和视图通过其进行通信的视图模型。 不一定是数据模型。 MVC项目模板有点令人困惑，因为开发人员认为MVC模型=数据模型。 在任何并非完全无关紧要的业务应用程序中（例如单组装简单应用程序），这都不相等。 最好不要这样。 特别是如果我们考虑共同关注点分离 。 除了数据层之外，我们不应在任何层中依赖特定的ORM类。

但是，如果您打算在MVC应用程序中使用DTO（作为视图模型），我建议您使用可以创建部分类的ORM，以便您可以轻松地在其上添加其他内容（例如属性）。 您的数据注释可以写在特殊的元数据类内部，该元数据类可以通过单个类级属性附加到模型类。

建议

但是我建议做其他事情。 与POCO一起使用一个单独的层，该POCO将在所有层上使用，并在上面带有数据注释。 这将使您的表示层独立于数据层，并且POCO也可能会进行表示优化（例如，具有一个名为UserRegistration的类，例如，它具有两个密码属性-也具有重复的值）。 数据层中的存储库将负责POCO转换，因此所有层将仅使用POCO而不是使用数据对象来交换数据。

ORM和类生成

使用Entity Framework，您确实获得了一个非常可控的环境，可以从数据存储架构生成类。 不幸的是，与他人不同。 生成不是全能的，但也可以手动控制和操纵（如果您想进行TPH / TPT结构）。

与LINQ to SQL类似。 我没有使用过任何其他ORM，但我想LinqConnect可能拥有与EF Visual Studio编辑器类似的自己的编辑器，因为我一直在使用同一家公司的MySql连接器，并且将它们的设计器用于实体，因为这样更好而不是Visual Studio 2008附带的版本。

但是您拥有提供代码生成的工具（并且您还可以在互联网上获得各种ORM的模板）：

• Visual Studio内置了T4，可以为您生成代码； 您还可以为用T4编写的ORM找模板，然后轻松地对其进行自定义。 或根据自己的需要编写自己的代码（过去我已经从数据库查找表中编写了枚举生成器）
• MyGeneration是开源的，您可以找到很多模板
• CodeSmith不是免费的，但它是我过去与.netTiers模板一起使用的一种经过验证的产品（在使用LINQ之前），它节省了大量时间，并且运行良好