用于 ASP.NET MVC 开发的 SubSonic 3、实体数据模型（实体框架）或 LINQ to SQL？
在使用了所有这些（其中一些比其他更多）之后，我仍然不确定哪个可能是最好的使用（使用 .NET 3.5）。开发时各自的优缺点是什么？
亚音速3
没有足够的示例/文档（我知道它是一个 wiki，人们可以更新它，但追踪事情可能很棘手 - 例如示例应用程序在哪里（WebForms、MVC（当前版本，而不是 3 之前的版本）、WinForms） ）。当我第一次尝试时，文本模板没有按预期工作。例如，它不会像 SubSonic 2 那样清理表名（例如删除/替换空格）。另外，您不能指定要包含哪些表，只能指定可以排除的表（在 ActiveRecord.tt 中）。 Context.tt 和 Structs.tt 为所有表生成代码（您可能不需要“aspnet_”表，也可能不需要其他一些表（会话表）） 。
尽管如此（希望我没有太严厉），除了一些小问题之外，它是一个很好用的 ORM。
实体数据模型（实体框架）
用于设置模型的视觉设计器。与数据库同步，可能被认为有点“冗长”并且难以理解。不过有相当不错的文档。但并没有走得更深入。
LINQ to SQL 还有一个用于创建模型的设计师。使用简单。功能比其他两个少。我还必须针对一个不起眼的错误应用修补程序（当模型具有非 int 类型的外键时不会更新）
NHibernate
以前看过这个，但与上面相比，设置起来并不那么容易。 有使用此示例的 ASP.NET MVC 应用程序吗？
理想情况下，我想要一个框架：
a）可以从数据库生成模型
b) 支持LINQ语法
c) 仅检索所需的数据（例如分页）
d) 允许数据注释
e) 可以生成 sql 来更新或在现有数据库中创建新表
Having used all of them (some more than others), I am still undecided on which could be the best to use (with .NET 3.5). What are the pro's and con's of each when developing?
SubSonic 3
Not enough samples/documentation (I know its a wiki and people can update it, but it can be tricky to track things down - e.g. where are the sample apps (WebForms, MVC (current version, rather than pre-3), WinForms)). Text Templates didn't work as expected when I first tried them. For example, it does not clean up the table names like SubSonic 2 did (removing/replacing spaces for example). Also, you cannot say which tables to include, just the ones you can exclude (in ActiveRecord.tt). Context.tt and Structs.tt generates code for all the tables (you would probably not want the 'aspnet_' ones, and probably some others (session tables) as well).
Saying that though (hope I'm not being too harsh), it is quite a good ORM to use, minor issues aside.
Entity Data Model (Entity Framework)
Visual Designer for setting up models. Syncs with database, might be considered a bit 'verbose' and hard to understand. There is fairly decent documentation though. Not gone that much further in depth though.
LINQ to SQL
Also has a designer for creating models. Simple to use. Less features than the other two. I also had to apply a hotfix for an obscure bug (wouldn't update when the model had foreign keys that were not of type int)
NHibernate
Looked at this in the past, but not that easy to set up compared to the above.
Any sample ASP.NET MVC apps using this?
Ideally I would want a framework that:
a) could generate the models from a database
b) support LINQ syntax
c) retrieve only the data that is needed (e.g. for paging)
d) allow data annotations
e) could generate the sql to update or create new tables in an existing database
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MVC 是表示层，ORM 是数据层
我不认为 ORM 与 MVC 应用程序有太多关系。至少如果您正确地对应用程序进行分层。 MVC 应用程序中的模型实际上是表示层视图的模型。控制器和视图通过其进行通信的视图模型。不一定是数据模型。 MVC 项目模板有点令人困惑，因为开发人员认为 MVC 模型 = 数据模型。在任何不完全琐碎的业务应用程序（如单个程序集的简单应用程序）中，这是不相等的。最好不是。特别是如果我们考虑关注点分离。我们不应该依赖数据层以外的任何层中的特定 ORM 类。
但是，如果您打算在 MVC 应用程序中使用 DTO（作为视图模型），我建议您使用创建部分类的 ORM，这样您就可以轻松地在它们上添加其他内容（如属性）。您的数据注释可以写入特殊的元数据类内部，该元数据类可以通过单个类级属性附加到您的模型类。
建议
但我建议做点别的事情。使用带有 POCO 的单独图层，该图层将在所有图层上使用，并在其上有数据注释。这将使您的表示层独立于数据层，并且您的 POCO 也可以进行表示优化（例如拥有一个名为 UserRegistration 的类，例如具有两个密码属性 - 也具有重复值）。数据层中的存储库将负责 POCO 转换，因此所有层将仅使用 POCO 而不是使用数据对象交换数据。
ORM 和类生成
使用实体框架，您确实可以获得一个非常可控的环境来从数据存储模式生成类。不幸的是，这与其他人不一样。生成不是全部的，但也可以手动控制和操作（如果您想做 TPH/TPT 结构）。
与 LINQ to SQL 类似。我没有使用过任何其他 ORM，但我猜 LinqConnect 可能有它自己的编辑器，类似于 EF Visual Studio 编辑器，因为我一直在使用同一家公司的 MySql 连接器，并且我使用了他们的实体设计器，因为它更好比 Visual Studio 2008 提供的工具要好。
但是您有提供代码生成的工具（您也可以在 Internet 上获取各种 ORM 的模板）：
MVC is presentation layer, ORM is Data layer
I don't think that ORM has
anythingso much to do with an MVC application. At least if you tier your application properly. Model in an MVC application is rather model of the presentation layer view. A view model through which controller and view communicate. Not necessarily data model. MVC project template is a bit confusing, since developers think that MVC model = data model. In any business application that is not completely trivial (like a single assembly simple application) this is not equal. And it's better that its not. Especially if we take into cosideration separation of concerns. We shouldn't rely on particular ORM classes in any layer other than data layer.But if you intend to use DTOs in your MVC application (as view models) I suggest you use that ORM that creates partial classes, so you can easily add additional stuff on them (like attributes). Your data annotations can be written inside of a special metadata class that can be attached to your model class by a single class-level attribute.
Suggestion
But I suggest doing something else. Use a separate layer with POCOs that will be used on all layers and would have data annotations on them. This will make your presentation layer independent of data layer and your POCOs may also be presentation optimised (like having a class called
UserRegistrationfor instance with two password properties - with repeated value as well). Your repository in your data layer would be responsible for POCO conversion so all layers will exchange data using POCOs only instead of using data objects.ORMs and class generation
With Entity Framework you do get a very controllable environment to generate your classes from a data store schema. Unfortunately it's not the same with others. Generateion is not all-in, but can be controlled and manipulated manually as well (if you'd like to do TPH/TPT structures).
Similar with LINQ to SQL. I haven't used any other ORM but I guess LinqConnect may have it's own editor similar to EF Visual Studio editor, because I've been working with MySql connector from the same company and I've used their designer for entities because it was better than the one provided with Visual Studio 2008.
But you have tools that provide code generation (and you can get templates on the internet for various ORMs as well):