我即将开始开发一个基于网络的应用程序,我可以将其描述为37Signal高层联系管理应用程序的专用版本,针对草坪护理等服务业务。我决定使用ASP.NET MVC来利用我的BizSpark成员资格并利用我已经知道的C#/ ASP.NET / SQL Server。
我正在做一些研究,为项目选择ORM;我不确定我是否应该使用LINQ to SQL之类的轻量级东西,或者使用NHibernate的大枪。在这一点上,我并不认为应用程序过于复杂。我基本上有这些模型:
适用以下业务规则:
我养成了尝试过度建设的坏习惯。 LINQ to SQL似乎可以立即满足我的需求,但我担心未来的可扩展性以及使用功能更丰富的ORM(如Entity Framework或NHibernate)的前期成本是否会在查询效率和优化。我正在考虑使用Windows Azure来托管应用程序。
有什么想法吗?
答案 0 :(得分:4)
您的模型看起来很简单,可以得到Linq2Sql,Entity Framework和NHibernate的支持。
您需要做的最大选择是,您希望遵循域驱动设计方法进行软件建模,还是希望将对象作为数据库行使用。如果您希望在将行映射到对象时获得乐趣,那么NHibernate是最佳选择。如果您对业务对象和数据库行Linq2Sql和Entity Framework之间的1:1感到满意就好了。
NHibernate并且在某种程度上,Entity Framework支持不从基类继承的POCO对象,并且可能不知道它们的持久性要求。 Linq2Sql可以,但它的hacky和怪异。
就扩展而言,所有这三个ORM工具都会让你走得很远AFAIK NHibernate在分割数据库服务器和处理跨数据库ID方面有更多的选择,甚至还有一些Sharding支持正在进行中。
NHibernate也支持大多数提供者,你可以在一小时内从MSSql转到MySql,用Linq2Sql和EF(虽然支持即将到来你不能)
所以TL; DR:
我已经使用了所有三个,我对EF1最不满意,EF4更好但不如NHibernate好。
我正在将VS4与VS 2010一起用于所有未来的“简单CRUD”应用程序和NHibernate,当我需要得到它的时候。
答案 1 :(得分:2)
我的经验是,实体框架的“前期成本”与简单数据模型的LINQ-to-SQL大致相同(假设您有一个现有的数据库架构可供使用)。
有关获得简单实体框架模型的series of tutorials可用。
我不是其中之一“LINQ-to-SQL已经死了!”人们,但看起来微软打算在未来的实体框架中投入更多资金。这对我来说略微偏向L2S。 ADO.NET team blog是一个值得关注的好地方。
答案 2 :(得分:1)
您可能需要考虑SubSonic。它似乎直接针对你的最佳位置。
之后,我会考虑NHibernate。 NHibernate具有最小的缺点,它可以有效地“缩小”到您的项目。使用NHibernate,您不会像使用Microsoft ORM和SubSonic一样将自己装入有限的功能集。
答案 3 :(得分:1)
受到运行stackoverflow.com的引擎的启发,我在过去几个月里一直致力于开发一个完整的CRM和一体化商业解决方案。关于使用LINQ to SQL作为ORM我有很多保留意见(关于stackoverflow.com和其他地方的讨论指出了Entity框架是'in thing'这一事实),然而,我发现LINQ to SQL变得轻而易举即使有其已知的局限性。使用LINQ-to-SQL,我可以在几周内构建一个功能齐全的原型CRM。目前,CRM处于测试的后期阶段,客户很少,其中一些使用量很大(1000个主要用户和几十个用户)。到目前为止,我还没有看到ORM /数据库有任何明显的停止显示的问题。
我编写了很多SQL存储过程(并将它们与LINQ to SQL一起使用),其中需要非常复杂的连接。由于我来自SQL / Microsoft企业库背景,我发现在SQL中编写复杂的存储过程并在LINQ to SQL层中保持基本的CRUD操作更容易
indyfromoz
答案 4 :(得分:1)
我目前正在收集一个asp.net mvc应用程序。我们使用了S#arp架构。它是一个“框架”,使开发人员能够利用NHibernate,Fluent和各种其他最佳实践工具(DI等)。这是该网站的链接。
http://wiki.sharparchitecture.net/
我们的团队非常喜欢这款产品,并建议任何人在决定架构路径时将其添加到他们的技术库中。
答案 5 :(得分:0)
我推荐这个:
正如我的前任老板所说,“你选择什么并不重要,选择一些东西并开始工作很重要”; - )