为“简单”SaaS启动选择ORM(ASP.NET MVC)

您的模型看起来足够简单,可以由linq2sql、实体框架和nhibernate支持。

您需要做的最大选择是,您希望遵循域驱动的软件建模设计方法,还是希望将对象作为数据库行来使用。如果您想在将行映射到对象时获得幻想,最好选择nhibernate。如果您对业务对象和数据库行linq2sql和实体框架之间的1:1满意的话。

nhibernate和某种程度上,实体框架支持POCO对象,这些对象不是从基类继承的,并且可能不知道它们的持久性需求。linq2sql可以,但是它有点古怪。

就扩展而言,所有这三个ORM工具都将为您提供相当远的距离,而Afaik Nhibernate在拆分数据库服务器和处理跨数据库ID方面有更多的选择,甚至在工作中还提供了一些切分支持。

nhibernate也支持最多的提供者,您可以在一个小时内从mssql转到mysql,使用linq2sql和ef(尽管支持即将到来,但您不能)

因此,TL;DR:

• 如果您想要更好的POCO支持、更多的缩放功能和“该行有一个映射”对象映射功能,请使用nhibernate。FluentHibernate很棒。您有多个提供商支持
• 实体框架,如果你想要更好的设计器图形用户界面支持,并愿意等待EF4,VS2010的功能齐全的ORM。
• linq2sql如果简单的数据库访问是你所需要的。

我已经用过这三种了,我对EF1最不满意,EF4更好,但不如NHiberinate好。

我正在使用EF4和Vs2010为所有未来的“简单积垢”应用程序和NHibernate时,我需要得到幻想。

我的经验是,实体框架的“前期成本”与简单数据模型的Linq to SQL大致相同(假设您有一个现有的数据库模式可供使用)。

一 series of tutorials 一个简单的实体框架模型的建立和运行是可用的。

我不是那种“Linq to SQL死了!”但看起来微软确实打算在实体框架方面加大投资。对我来说,这个天平比L2S稍微倾斜一点。 ADO.NET team blog 是一个很好的地方来关注这个。

你可能想考虑亚音速。它似乎直接瞄准你的最佳位置。

在那之后,我会考虑使用氨气。NHibernate有最小的缺点,它可以有效地“缩小”到您的项目。使用nhibernate,您不会像使用Microsoft Forms和Subsonic那样限制自己使用有限的功能集。

在StackOverflow.com的引擎的启发下,我在过去几个月一直致力于开发一个全面的CRM和企业预置型解决方案。我对使用linq-to-sql作为ORM(stackoverflow.com和其他网站上的讨论指出,实体框架是一个“有用的”事实)有很多保留意见,但是,我发现linq-to-sql很容易使用,即使有已知的限制。有了linq-to-sql,我可以在几周内构建一个完整的功能原型CRM。目前,CRM正处于测试的后期阶段,客户很少,其中一些客户的使用量相当大(1000多个潜在客户和几十个用户)。到目前为止,我还没有看到任何明显的、显示出停止ORM/数据库的问题。

我编写了相当多的SQL存储过程(并将它们与LINQ to SQL一起使用),其中需要非常复杂的连接。因为我来自SQL/Microsoft企业库背景,所以我发现用SQL编写复杂的存储过程和将基本CRUD操作保持在LINQ to SQL层中更容易。

因德罗莫茨

我目前正在包装一个ASP.NET MVC应用程序。我们使用了S ARP架构。它是一个“框架”,使开发人员能够利用NHibernate、Fluent和大量其他最佳实践工具(DI等),这里是到该站点的链接。

http://wiki.sharparchitecture.net/

我们的团队绝对喜欢这个产品,并建议任何人在决定架构路径时将它添加到他们的技术库中。

我建议这样做:

1. S ARP架构。它使用NHibernate,但是它是高度预配置的,这样你就可以在几分钟内启动和运行——不仅有数据,还有MVC和其他有用的东西。
2. ActiveRecord实现-即, Castle ActiveRecord . thsi很容易使用,但你还是需要了解一点nhiberinate。
3. 具有存储库模式的Linq to SQL。您将受益于L2的简单性,同时也将准备好未来的更改。只需谷歌搜索“Linq to SQL知识库”。

正如我的前任老板所说,“你选择什么并不重要,重要的是选择一些东西并开始工作。”—)