问题描述
Microsoft Linq to SQL、Entity Framework (EF) 和 nHibernate 等都在提出 ORMS 作为下一代数据映射技术，并声称它是轻量级、快速和简单的.比如这篇刚刚发表在 VS 杂志上的文章:
Microsoft Linq to SQL, Entity Framework (EF), and nHibernate, etc are all proposing ORMS as the next generation of Data Mapping technologies, and are claiming to be lightweight, fast and easy. Like for example this article that just got published in VS magazine:
http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583
谁都对在他们的项目中实施这些技术感到兴奋?这些技术的创新之处在哪里，使它们比前辈更出色?
Who all are excited about implementing these technologies in their projects? Where is the innovation in these technologies that makes them so great over their predecessors?
推荐答案
多年来，我在数百个应用程序中编写了数据访问层、持久性组件，甚至我自己的 ORM(我的爱好"之一)；我什至实现了我自己的业务交易管理器(在 SO 的其他地方讨论过).
I have written data access layers, persistence components, and even my own ORMs in hundreds of applications over the years (one of my "hobbies"); I have even implemented my own business transaction manager (discussed elsewhere on SO).
ORM 工具在其他平台上已经存在了很长时间，例如 Java、Python 等.现在以 Microsoft 为中心的团队已经发现了它们，这似乎是一种新的时尚.总的来说，我认为这是一件好事——探索和理解似乎随着 .NET 的到来而引入的架构和设计概念的旅程中的必要步骤.
ORM tools have been around for a long time on other platforms, such as Java, Python, etc. It appears that there is a new fad now that Microsoft-centric teams have discovered them. Overall, I think that is a good thing--a necessary step in the journey to explore and comprehend the concepts of architecture and design that seems to have been introduced along with the arrival of .NET.
底线:我总是更喜欢自己访问数据，而不是与一些试图帮助"我的工具作斗争.放弃我对自己命运的控制是永远不能接受的，数据访问是我的应用程序命运的关键部分.一些简单的原则使数据访问非常易于管理.
Bottom line: I would always prefer to do my own data access rather than fight some tool that is trying to "help" me. It is never acceptable to give up my control over my destiny, and data access is a critical part of my application's destiny. Some simple principles make data access very manageable.
使用模块化、抽象和封装的基本概念——因此将您平台的基本数据访问 API(例如 ADO.NET)与您自己的层包装在一起，从而将抽象级别提高到更接近您的问题空间.不要直接针对该 API 编写所有数据访问(也在 SO 的其他地方讨论过).
Use the basic concepts of modularity, abstraction, and encapsulation--so wrap your platform's basic data access API (e.g., ADO.NET) with your own layer that raises the abstraction level closer to your problem space. DO NOT code all your data access DIRECTLY against that API (also discussed elsewhere on SO).
严格应用 DRY(不要重复自己)原则 = 重构数据访问代码中的日光.在适当的时候使用代码生成作为重构的手段，但尽可能地消除对代码生成的需要.通常，代码生成表明您的环境中缺少某些东西——语言缺陷、内置工具限制等.
Severely apply the DRY (Don't Repeat Yourself) principle = refactor the daylights out of your data access code. Use code generation when appropriate as a means of refactoring, but seek to eliminate the need for code generation whenever you can. Generally, code generation reveals that something is missing from your environment--language deficiency, designed-in tool limitation, etc.
同时，学习如何很好地使用可用的 API，尤其是在性能和健壮性方面，然后将这些课程融入您自己的抽象数据访问层中.例如，学习在 SQL 中正确使用参数，而不是将文字值嵌入 SQL 字符串中.
Meanwhile, learn to use the available API well, particularly regarding performance and robustness, then incorporate those lessons into your own abstracted data access layer. For example, learn to make proper use of parameters in your SQL rather than embedding literal values into SQL strings.
最后，请记住，任何成功的应用程序/系统都会遇到性能问题.修复性能问题更多地依赖于将它们设计出来，而不仅仅是在实现中调整"某些东西.该设计工作将影响必须同步更改的数据库和应用程序.因此，寻求能够轻松(敏捷)进行此类更改，而不是试图避免更改应用程序本身.在某种程度上，这最终意味着能够在不停机的情况下部署更改.如果你不远离它设计"，这并不难.
Finally, keep in mind that any application/system that becomes successful will grow to encounter performance problems. Fixing performance problems relies more on designing them out rather than just "tweaking" something in the implementation. That design work will affect the database and the application, which must change in sync. Therefore, seek to be able to make such changes easily (agile) rather than attempt to avoid ever changing the application itself. In part, that eventually means being able to deploy changes without downtime. It is not hard to do, if you don't "design" away from it.
这篇关于这里的每个人都跳上 ORM 的潮流吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！