ORM/持久层推荐我正在开始一个新项目，我正在寻找一个非常好的基于ORM或非SQL的持久层。对于这个项目，我不太关心数据是如何持久化的，只要能以合理的速度查询和存储，最重要的是简单的查询。并发应该无缝处理（前端将在另一层，并且会有多个并发用户，但不一定处理相同的数据）并且我必须较少关注数据层（简单查询，自动延迟加载等））多好。我还想不惜一切代价避免基于字符串的查询，因此支持LINQ或其他直观且可能是强类型查询的工具将是一个很大的好处。最后，使用POCO对象是我真正想做的另一件事这是我评估过的产品列表以及它们不适合的原因，只是为了让我看不到任何关于使用它们的建议：我还查看了MongoDB和CouchDB，但在这些情况下，相关对象的捕获看起来像是在做正确的事情之前需要进行过多的测试。此外，它们都不提供强类型查询。提前感谢您的建议！如果你能负担得起LLBLGen许可证，那就去买吧。我越用越不喜欢LINQ查询语法（尽管我喜欢与扩展方法和表达式树相关的语言特性）。一开始我喜欢和其他人一样，但不确定XYZLINQ提供程序中的[[whereemployee.Name.StartsWith("JohnSmit")]]是在SQL语句中还是在LINQtoObjects中完成（其中SQLreturnsafter)results），以及[[user.Roles.Contains(role)]]是否有效是一大步。LLBLGen可以删除所有项目而不加载它们MyEntityCollection.DeleteAll(newMyEntity{Condition=value});很简单，我喜欢。使用PrefetchAPI默认和/或每个查询设置，您将获得延迟加载和急切/深度加载。您可以动态地（轻松地）构建和构建无限级别的任何过滤器/排序/加载。这很好。LLBLGen只有两个问题：首先，并非所有公司都愿意支付这个价格，尤其是考虑到围绕微软替代方案的大肆宣传。其次，命名约定虽然在RDBMS理论中是标准的），比如PredicateFactory代替“where”或“filter”，Prefetch代替深度加载，甚至SortExpression代替orderby，对于第一个使用它的开发人员来说，这些有点吓人有时，但很快你就会学会爱他们，因为他们给予你力量和轻松。在LLBLGen3.0中有关于POCO支持的讨论。我不知道，因为我不知道。现在，鉴于我不再在使用LLBLGen的公司工作，该公司使用LINQtoSQL主要是因为它在很多项目中都得到了“认证”，没有出现重大故障（不像EF1，后者缺少LINQtoSQLLINQ功能和非常差的性能，在高级映射中可能非常有限-它应该是最好的！）。我在这家公司使用过这两种产品，但都讨厌。新项目的决定仍然是LINQtoSQL并尽我们所能克服它的局限性。这个站点StackOVerflow本身运行在它之上！你可以解决它来做SEMI-POCO（当涉及到关联时，你仍然需要使用一些L2S相关的类型）。我也在家里做一些小项目。由于我不再拥有LLBLGen许可证，我决定学习NHibernate并将其与FluentNHibernate和LINQToNHibernate一起使用。我从中了解到NHibernate非常强大。它改变了我处理诸如自动更新数据库模式之类的事情的方式（我在使用它时几乎从未接触过D）。LINQ提供程序（在NHibernateContrib项目中）有时相当缺乏，但NHibernate的未记录源本身包含一个更好的LINQ提供程序（尚未尝试）。类似于L2S中的DataContext或EF中的ObjectContext进行Web开发时，NHibernate中的“会话”可能会出现问题（LLBLGen不会因为自我跟踪实体而受到影响）。NHibernate的最大问题是查找信息的能力。太多的部分应该以某种方式组合在一起并且没有太多指导可以包含用于映射和查询的高级信息。如果不是我的一个朋友（TunaToksoz，推特上的@tehlike）碰巧是NHibernate项目源代码的提交者，我就会遇到真正的麻烦。我学到的道理是：如果你想要一些可以正常工作的东西并且有点基本使用LinqToSql或SubSonic，如果你想要介于你的生产环境之间的东西可以负担得起BETA.NET版本（假设golive存在）使用EntityFramework4.0如果你想要一些真正强大的东西并且能够负担得起艰苦的学习过程，那就去NHibernate，最重要的是，如果你能负担得起LLBLGen，请使用它。看看DataObjects.Net：优点：缺点：在所有方面，我倾向于完全不同意您对NHibernate弱点的评估。我认为XML映射非常简单直观。添加对NHibernate.dll的引用并创建SessionFactory也很简单。维护和变更管理大大简化。会话工厂和会话非常容易理解和处理。总的来说，我认为你的评估是感性的而不是理性的。您是否考虑过使用面向对象的数据库，例如db4o。虽然我从来没有用过它，但当我发现它时，我发现它很有趣：它支持LINQ查询，使用POCOs，如果我理解正确的话，数据只是存储在一个文件中（不需要安装数据库）。一些链接：教程、论坛帖子LLBLGEN。如果您认为自己会找到符合要求的东西，那么您可能需要等待很长时间。编写自己的ORM听起来很疯狂，但您可以编写自己的ORM。有时回到项目中，客户不想使用第3方工具或库，所以我们最终编写了自己的ORM，它给了我们一个特定的目标。您可以使用属性修饰对象类和属性，以将它们映射到数据库表和字段。拥有所有业务对象的基类，并使用反射对对象执行数据库操作。这样您就可以构建自己的小型ORM来满足您想要的特定目标。供您参考，它可能看起来有点像这样。[TableMapping("Users","User","Users")]publicclassUser:EntityBase{#regionConstructor(s)publicUser(){}#endregion#regionProperties#region默认属性-使用DataFieldMappingAttribute私有的直接字段映射System.Int32_UserId;私人System.String_UserName;[DataFieldMapping("UserID")][DataObjectFieldAttribute(true,true,false)][NotNullOrEmpty(Message="UserIDIsRequired.")]publicoverrideintId{get{return_UserId;}设置{_UserId=值；}}[DataFieldMapping("UserName")][NotNullOrEmpty(Message="UsernameIsRequired.")]publicstringUserName{get{return_UserName;}设置{_UserName=值；}}#endregion#region一对多映射#endregion#region派生属性#endregion#endregion}我用过LLBLGenPro、NHibernate和一些对象数据库。我的第一个建议是NHibernate和FluentNhibernate来处理映射。我发现与使用NHibernate相关的困难90%与XML映射直接相关。当我切换到FluentNhibernate时，疼痛消失了。另外10%的困难只是无知；我不明白。这不是NHibernate的错。LLBLGenPro：我不知道现在对Linq的支持是什么样的，但在支持Linq之前，它是一个用于编写查询的PITA。我阅读了文档并明白了，但我的同事却没有，并且无休止地抱怨诸如预取路径之类的复杂问题。另外，就像你说的-不是POCO。加上成本，我会说麻烦多于它的价值。如果不是client-server架构，我推荐db40。我在一个小型私人项目上使用它并且喜欢它。便于使用。伟大的小对象数据库。看看实体空间。我不能根据我的个人经验推荐，但对于我的一位同事来说，它非常有用（不是那些......）在这里查看Aspectize对我来说，答案已被证明是LLBLGenPro。除了它的功能之外，您还有一个专门的支持团队，他们关心帮助您完成项目，如果您发现错误，在大多数情况下，您会在几小时或几天内修复它。这不能最小化，因为它允许您继续工作而不是等待发布（几个月？）或自己修复错误。你可以看看TelerikORM。我没有在生产中使用过它，但它基于几年前为我工作的名为POET的JavaORMODB。由于它使用装配增强功能，因此它提供了比您可能拒绝的某些产品更透明的体验。对于纯ODB，Versant的FastObjects值得一看。祝你好运-让我们知道你决定采用什么。以上就是C#学习教程的全部内容：ORM/持久层建议分享。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右边联系管理员删除。如需转载请注明出处：
