Questions tagged «orm»

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意测验或进一步的讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 9年前关闭。 我开始使用我选择的框架推荐的ORM，尽管我喜欢ORM提供的附加抽象层的想法，但我开始意识到这实际上意味着什么。这意味着我不再使用数据库（mysql），并且所有特定于mysql的功能都消失了，就像它们不存在一样。 ORM的想法是，它试图通过使所有数据库不可知来帮助我。这听起来不错，但是通常我选择特定的数据库系统是有原因的。但是通过走数据库不可知路线，ORM会采用最低的公分母，这意味着我最终会获得最小的功能集（所有数据库都支持这些功能）。 如果我知道从长远来看不会切换基础数据库怎么办？为什么还不访问特定于数据库的功能？

19 database-development  orm 

如果我将所有业务逻辑都包含在代码中并使用Entity Framework，那么在什么情况下（如果有），将某些业务逻辑移至存储过程中而不是将其全部保留在代码中会更好吗？ 需要明确的是，我的意思是与当前设置（代码中的业务逻辑）结合使用，而不是与其结合使用。我已经看到了许多类似的问题，这些问题都要求在存储过程中拥有所有业务逻辑的利弊，但是对于保留少量使用边缘过程逻辑的同时保留其余业务逻辑的情况，我没有发现太多的益处在代码中。 如果有所作为，我正在使用MSSQL和Entity Framework。 在以下情况下，我曾使用过存储过程： 一份复杂的报告需要几分钟才能运行（这是Web应用程序中的页面）。我发现我可以编写比LINQ提供的SQL更有效的SQL（只需花费几秒钟即可运行）。 一个Web应用程序需要读写一个单独数据库中的几个表，其中包含许多其他与该应用程序无关的敏感信息。我没有给它访问所有内容的权限，而是使用了一个存储过程，该过程仅执行所需的操作，并且仅返回有限的信息。然后，可以只给Web应用程序访问此存储过程的权限，而不能访问任何表等。 在问这个问题之前，我查看了其他帖子： 存储过程是全球最大的IT软件咨询公司之一的不良做法？ 在Web应用程序的存储过程中保存所有业务逻辑的利弊 /programming/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code /dba/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452 什么时候不使用ORM而更喜欢存储过程？

19 design  sql-server  orm  business-logic  stored-procedures 

今天，我与组织中的另一位开发人员进行了激烈的辩论，讨论在何处以及如何向数据库映射的类中添加方法。我们使用sqlalchemy，并且数据库模型中现有代码库的主要部分不过是一袋带有类名的映射属性，几乎是从数据库表到python对象的机械翻译。 在论点中，我的立场是使用ORM的主要价值是可以将低级行为和算法附加到映射的类。模型首先是类，其次是持久性的（使用文件系统中的xml可以持久性，您无需关心）。他的观点是，任何行为都根本就是“业务逻辑”，并且必然属于持久性模型之外的任何地方，而持久性模型仅用于数据库持久性。 我当然确实认为，什么是业务逻辑，应该分开，因为它与实现方法的较低层和域逻辑之间存在一定的区别，我认为这是模型类提供的抽象。在上一段中讨论过，但是我很难理解那是什么。我对API可能有什么更好的理解（在我们的例子中是HTTP“ ReSTful”），因为用户以他们想做的事情调用API，这与他们被允许做的事情以及如何做不同。完成。 tl; dr：使用ORM时，可以或应该在映射类的方法中进行哪些操作，应该忽略哪些内容以驻留在另一层抽象中？

16 orm  abstraction  business-logic 

这是一种常见情况： 您需要在使用ORM框架的应用程序中实现批量操作。 第一次通过之后，您已经注意到严重的性能问题。 这是我的问题： 在这种情况下，您是否应该支持包含原始SQL的解决方案？ 还是有众所周知的设计模式可以帮助您缓解与ORM框架的批量操作通常相关的问题？ 编辑： 我不是问您是否应该从整个应用程序中删除ORM框架。 我在问：您是否应该为该应用程序的这一小部分放弃ORM框架？

15 orm  heuristics 

Doctrine和Propel都利用单个和具体的表继承来映射对象关系。前者将类树中所有可能的字段映射到单个表，而后者将每个类都映射到特定表，从而在继承层次结构中复制了公共字段。 虽然这有利于ORM设备，但对我来说建议数据库设计不好。这些错误的设计模式是否可以在数据库上执行？

14 database-development  database  orm 

我一直在尝试创建一个网站，该网站将MVC和JSON用于我的表示层，以及用于数据模型/数据库的Entity框架。我的问题与将模型对象序列化为JSON有关。 我正在使用代码优先方法创建数据库。在执行代码优先方法时，一对多关系（父/子）要求子对父有引用。（示例代码是我的错字，但您会看到图片） class parent { public List<child> Children{get;set;} public int Id{get;set;} } class child { public int ParentId{get;set;} [ForeignKey("ParentId")] public parent MyParent{get;set;} public string name{get;set;} } 通过JsonResult返回“父”对象时，由于“子”具有父类的属性，因此引发循环引用错误。 我已经尝试了ScriptIgnore属性，但是无法查看子对象。在某些时候，我将需要在父子视图中显示信息。 我试图为没有循环引用的父级和子级创建基类。不幸的是，当我尝试发送baseParent和baseChild时，它们被JSON分析器读取为它们的派生类（我很确定此概念正在使我逃避）。 Base.baseParent basep = (Base.baseParent)parent; return Json(basep, JsonRequestBehavior.AllowGet); 我想出的一个解决方案是创建“查看”模型。我创建数据库模型的简单版本，其中不包含对父类的引用。这些视图模型每个都有返回数据库版本的方法和一个将数据库模型作为参数的构造函数（viewmodel.name = databasemodel.name）。尽管此方法有效，但似乎是强制的。 注意：我在这里发布是因为我认为这值得讨论。我可以利用其他设计模式来解决此问题，也可以像在模型上使用其他属性一样简单。在搜索中，我没有找到克服此问题的好方法。 我的最终目标是拥有一个很好的MVC应用程序，该应用程序充分利用JSON与服务器进行通信并显示数据。同时跨层维护一致的模型（或尽我所能）。

13 asp.net-mvc  entity-framework  orm  json 

除了（ActiveRecord）模型外，我还始终在数据库级别应用约束。但是我一直在想这是否真的必要吗？ 一点背景 最近，我不得不对模型的基本自动时间戳生成方法进行单元测试。通常，测试会创建模型的实例并保存而不进行验证。但是表定义中还有其他必填字段不能为空，这意味着即使我跳过ActiveRecord验证，也无法保存实例。因此，我在考虑是否应该从数据库本身中删除此类约束，并让ORM处理它们？ 如果我跳过db，imo中的约束，可能的优点 - 可以修改模型中的验证规则，而不必迁移数据库。 可以跳过测试中的验证。 可能的缺点？ 如果可能ORM验证失败或被旁路，则数据库不会检查约束。 你怎么看？ 编辑在这种情况下，我使用的是Yii Framework，它从数据库生成模型，因此也生成了数据库规则（尽管我总是可以自己在生成后编写它们）。

13 database  orm  validation  dry 

我正在使用PetaPoco微型ORM。使用ORM工具处理数据库确实非常容易且安全，但是我唯一讨厌的是额外的代码。我曾经将大多数代码放在数据库本身中，并使用了所有RDBMS功能（如存储过程，触发器等），这些功能旨在更好地处理。 我想知道何时不对存储过程/触发器使用ORM，反之亦然。

13 orm  rdbms  stored-procedures 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 Java的持久性 在过去的几年中，我使用EJB 2.0，Hibernate，JPA和自家的概念，在Java持久性抽象领域积累了经验。在我看来，他们的学习曲线陡峭且复杂。另外，作为SQL的忠实拥护者，我还认为许多抽象模型都提供了过多的SQL抽象，从而创建了诸如“标准”，“谓词”，“限制”之类的概念，这些概念是非常好的概念，但对SQL却不是。 Java中的持久性抽象的一般思想似乎是基于对象关系模型的，其中RDBMS以某种方式与OO世界相匹配。ORM辩论一直以来都是一种激动人心的辩论，因为似乎没有一个适合所有人的解决方案-甚至可以存在这样一种解决方案。 OO 我个人对避免ORM相关问题的偏爱是坚持关系世界。现在，数据模型范式的选择不应成为讨论的话题，因为它是个人喜好，或者是哪种数据模型最适合具体问题。我想开始的讨论围绕着我自己的持久性工具jOOQ进行。我设计了jOOQ，以提供现代持久性工具具有的大多数优势： 基于SQL的领域特定语言 源代码生成将基础数据库模式映射到Java 支持许多RDBMS 添加一些现代持久性工具所没有的功能（如果我错了，请纠正我）： 支持复杂的SQL-联合，嵌套选择，自联接，别名，case子句，算术表达式 支持非标准SQL-存储过程，UDT，ENUMS，本机函数，分析函数 请查看文档页面以获取更多详细信息：http : //www.jooq.org/learn.php。您将看到在Linq中为C＃实现了非常相似的方法，尽管Linq并非专门为SQL设计的。 问题 现在，说了我是SQL的忠实拥护者，我想知道是否其他开发人员也会分享我对jOOQ（或Linq）的热情。这种持久性抽象方法是否可行？您可能会看到哪些优点/缺点？我如何改善jOOQ，您认为有什么缺失？从概念上或实践上我哪里出了问题？ 批判但建设性的答案表示赞赏 我知道这场辩论是一场感性的辩论。有许多很棒的工具已经在做类似的事情。根据您自己的经验或您可能已阅读的文章，我感兴趣的是至关重要但具有建设性的反馈。

12 java  orm  database  linq 

我最近阅读了很多关于将存储库模式与功能强大的ORM（例如Entity Framework）一起使用的争论，因为它结合了类似存储库的功能以及工作单元功能。 另一个反对在单元测试之类的情况下使用该模式的论点是，存储库模式是一种泄漏抽象，因为更通用的实现利用了IQueryable。 反对使用存储库模式的论点对我来说很有意义，但是建议的替代抽象方法通常更令人困惑，并且看起来像问题一样矫kill过正。 吉米·鲍嘉（Jimmy Bogards）的解决方案似乎既要吹散抽象，又要介绍自己的体系结构。 https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/ 另一个不必要的存储库示例....但是使用我的体系结构！ http://blog.gauffin.org/2012/10/22/griffin-decoupled-the-queries/ 另一个... http://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework 我还没有找到一种明显的替代或替代方法，而该替代方法本身并不具有更多的体系结构，因此可以替代“过于复杂”的存储库模式。

12 domain-driven-design  entity-framework  orm  nhibernate  repository-pattern 

我相信，如果您的存储库使用的是ORM，那么它已经足够从数据库中提取出来了。 但是，在我现在工作的地方，有人认为我们应该有一个抽象ORM的层，以防我们以后要更改ORM。 创建一个可以在许多ORM上使用的层真的必要吗？ 编辑 只是为了提供更多细节： 我们有与AutoMapper映射的POCO类和实体类。实体类由存储库层使用。然后，存储库层使用附加的抽象层与Entity Framework进行通信。 业务层决不能直接访问实体框架。即使在ORM上没有附加的抽象层，这一层也需要使用使用存储层的服务层。在这两种情况下，业务层都与ORM完全分开。 主要论据是将来能够更改ORM。因为对我来说，它确实是本地化的，所以它已经很好地分离了，我不明白为什么要使用一个附加的抽象层才能具有“质量”代码。

12 database  orm 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 2年前关闭。 考虑一下面向对象的编程语言（如C ++或Java）的通用教程：创建一个简单的订单处理系统，其中的对象代表帐户，订单，项目等（或多或少的等效对象）。完全具有直觉意义，但餐桌上的大象认为它不是真实的，因为它们是内存中的对象。在实际系统中，帐目，订单等实际上并没有真正存在于内存中，而是存在于数据库中，而内存表示只是它们的短暂镜像。 您可以自己编写很多代码来读取和写入数据库，但这是如此乏味且容易出错，实际上没有人这样做。 每个人最终都使用ORM，但是它们本身就存在问题，以至于著名的论文称它们为“我们行业的越南”。 我认为这不是对象和关系之间的不匹配，而是编程语言和数据库之间的不匹配，因为它们是彼此不了解的独立事物。猜想：解决方案是使用一种既是编程语言又是数据库查询语言的语言，这又将要求语言运行时也是数据库，而JIT编译器也必须是查询优化器。 这就是我所看到的问题的摘要。我的问题是，有没有人， 实际上建立了这样一个统一的系统 尝试过但未能建立这样的统一系统 关于如何构建这样的主题，或者为什么或为什么不这样做，写了很多实质性的文章 提出解决问题的替代方法？

11 database  language-design  orm 

我过去使用过MDA（模型驱动的体系结构）工具，我们通过UML进行建模，这会生成业务实体（我们的域模型）和ORM（映射等）。 该域上的许多业务代码和服务都是该模型的一部分，并且我们的存储库正在返回业务实体（因此，不可能切换到另一个ORM（不是我们想要的））。 但是，现在我正在开始一个项目，我想从DDD角度进行思考。 到目前为止，感觉好像我将业务逻辑放入域模型中，并通过存储库与ORM（无论选择哪种）一起使用。但是，如果我想继续在应用程序的ORM部分中使用MDA工具，则此处创建的模型将非常贫乏（即不包含任何业务逻辑）。同样，如果我将实体框架（.net）或NHibernate用于我的ORM，它也将是贫血模型。我不确定如果我刚刚使用NHibernate，您会将业务逻辑放在哪里。 我是否以这种方式正确思考，换句话说，使用DDD使用域中的所有业务逻辑，而仅使用ORM通过存储库进行持久化？

10 orm  entity-framework  domain-model  nhibernate  domain-driven-design 

首先，我说我已经使用SQL完成了95％的数据库工作。最近，我对各种ORM（例如NHibernate和Doctrine）进行了调查。 我可以看到不需要了解很多SQL和ORM提供的数据库可移植性的优点。但是我还可以看到，了解SQL将使使用ORM更加有效，而且我只能在职业生涯中一次想到，应用程序最大的改变就是数据库供应商。 因为我很舒服地编写SQL，并且显然没有意识到使用ORM的通常所教的好处，所以我对大量ORM用户的疑问是： 哪种Web开发项目从使用ORM中受益最大？

10 php  asp.net  sql  ruby-on-rails  orm 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 我正在研究将要进行的新项目的Entity Framework，并且作为对它的研究的一部分，我向一些行业专业人员询问它是否稳定并且为“现实世界”的实施做好了准备。 在运行中是： 英孚 NHibernate DevExpress XPO 我已经在XPO方面拥有丰富的经验，但是我对此并不特别满意。

10 .net  orm  entity-framework