ORM工具或手动将对象构建到关系映射层
我试图确定在构建数据层时使用对象到关系映射层(如 Hibernate 或 Microsoft 实体框架)是否有任何优点或缺点。
从长远来看,手动使用 SQL 和映射对象是否更好,还是利用这些映射技术之一更好?
对于简单的应用程序来说,额外的映射层似乎是有利的,因为该工具可以处理简单的映射和 SQL,从而节省一些时间,但是当您的对象模型变得更加复杂时怎么办?
如果有的话,对性能有何影响?
感谢您提供的任何见解。
I am trying to determine what if any advantage or disadvantage there is to using an object to relational mapping layer like hibernate or the Microsoft Entity framework when building the data layer.
Is using sql and mapping objects by hand better in the long run or is it better to leverage one of these mapping technologies?
It seems like for simple apps the additional mapping layer might be advantageous because the tool can handle the simple mapping and sql therefore saving some time, but what about when your object models become more complicated?
Also what are the performance implications if any?
Thanks for any insight you might have.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
最好的选择是确保无论您做什么,都可以在以后进行更改。因此,如果您使用 NHibernate 或 EF,您将希望框架的实际依赖关系保持在非常紧密的范围内;手动实现也是如此。
尝试实现存储库模式,然后您可以构建 NH-repo、EF-repo 等,然后看看哪个最适合您的需求。
我个人的观点是进行正确的 OR 映射(无论是手动还是通过框架)——这里的含义是您的业务/域对象不只是看起来像您的表,反之亦然。 ORM 的全部意义不仅仅是将数据从数据库中获取到应用程序中(数据集就可以做到这一点),而是让您在应用程序中充分利用 OOP 的优点,并且后端的 RDBMS。
如果您只是使用 SQL 作为“哑存储”(我最喜欢的用法),那么您可以考虑使用 OODB 或其他对象持久方法。在业余爱好/业余项目中探索这始终是一件有趣的事情——但很难向管理层推销(他们喜欢他们的 SQL Server),但它值得考虑。
当然,如果您谈论的是非常小的应用程序,那么也许您可以遵循 Active Record 模式或事务脚本模式来实现一些东西——XScript 非常适合非常小的应用程序,但扩展性不好——而 Active Record 非常适合数据输入/CRUD 应用程序
Your best option is to ensure that whatever you do, you keep the ability to change it later available. So if you go NHibernate or EF, you'll want the actual dependencies on the frameworks kept in a very tight are; same for manual-implementations.
Try implementing the Repository pattern, you could then build an NH-repo, EF-repo, etc, etc. and see which fits yours needs best.
My personal opinion is to do proper OR-Mapping (whether by hand or by framework)--the implication here is that your business/domain objects do not just look like your tables, and vice-versa. The whole point of an ORM isn't just to get data out of the database and into your application (DataSets were fine for that), but to let you take advantage of the best-of- both-worlds of OOP in your application and an RDBMS in your backend.
If you're just using SQL as "dumb-storage" (my favorite usage of it) then you could consider using an OODB or other object-persistance approach. This is always a fun thing to explore in hobby/side projects--but it's a hard case to sell to management (they looove their SQL Server), but it's worth a consideration.
Of course, if you're talking very small application, then perhaps you could implement something either following the Active Record pattern or perhaps the Transaction Script pattern--XScript is great for very small apps, but doesn't scale well--and Active Record is perfect for data-entry/CRUD applications
实际上,我'我想说的是恰恰相反。
在具有复杂对象模型的大型应用程序中使用 ORM 更有意义:
对于具有简单 DB 模型的非常小的应用程序,ORM 可能有点过大,因为持久层将相当容易实现,而无需引入某处存在错误,ORM 不会为您节省太多工作。
另一方面,对于具有更复杂数据库数据模型的大型应用程序,您的
JOIN
和UPDATE
等更容易出错,因此ORM 可能真的很有帮助。Actually, I'd say it's the other way around.
It makes more sense to use an ORM in a larger application that has a complex object model:
For very small applications with a simple DB model, an ORM is probably overkill, since the persistence layer will be rather easy to implement without introducing bugs somewhere, and an ORM won't save you much work.
On the other hand, with a large application having a more complex DB data model, it's easier to get your
JOIN
s and yourUPDATE
s etc. wrong, so an ORM might really be helpful.如果这是一个“我是否应该使用 ORM?”的问题,那么您的问题没有绝对的答案,每种方法都有权衡,既有积极的方面,也有消极的方面。
ORM 可以帮助您快速启动并运行,特别是当您拥有更大的数据模型时。如果您需要生成多个不同的持久层,它们也可能非常有用,因为您支持多个数据库供应商使用相同版本的产品。 ORM 不再像以前那么糟糕,它们现在相当高效。
就我个人而言,虽然我不喜欢它们 - 我认为如果您对数据库技能有一半的熟练程度,那么您应该使用它们。我认为 ORM 倾向于使开发人员免受数据库复杂性的影响,这不一定是一件好事。我喜欢调整我的数据访问和存储,虽然编写代码将数据集映射到域对象可能很乏味,但并不那么困难或容易出错,而且我确切始终知道发生了什么,任何地方都没有发生魔法。如果存在性能问题或效率低下,那么我可以非常快速地找到它们并修复它们。
If this is a question of "should i use an ORM or not?" then there is no absolute answer to your question, each approach has trade-offs, both positive and negative aspects.
ORMs can help you get up and running pretty quickly, especially if you have a larger data model. They can also be excellent if you need to generate several different persistence layers because you support multiple database vendors with the same version of your product. ORMs are not as bad as they used to be, they are reasonably efficient these days.
Personally though i'm not a fan of them - i think that if you are halfway proficient with your database skills then you should use them. I think that ORMs tend to shield developers from database complexities, which is not necessarily a good thing. I like to tune my data access and storage, and while writing code to map datasets to domain objects can be tedious it isn't that hard or error prone and i know exactly what is going on at all times, there is no magic happening anywhere. If there are performance problems or inefficiencies then i can very quickly track them down and fix them.
您可以构建自己的 ORM 映射工具。例如这里
http://askcode Generation.com/php/generate-propel-schema -for-php-symfony/
一个 propel orm 模式是从一个简单的描述类格式生成的(没有什么可以阻止为任何其他语言(如 c#)和任何 orm 框架(如 Hibernate)执行此操作,事实上,将来我打算这样做):
You could build your own ORM mapping tool. For example here
http://askcodegeneration.com/php/generate-propel-schema-for-php-symfony/
A propel orm schema is generated from a simple description class format (nothing prevents to do it for any other language like c# and any orm framework like Hibernate, in fact in the future I intend to do so):