Microsoft Linq to SQL,Entity Framework(EF)和nHibernate等都提议将ORMS作为下一代数据映射技术,并声称它们轻量级,快速且简单.例如刚刚在VS杂志上发表的这篇文章:
http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583
谁都对在项目中实施这些技术感到兴奋？这些技术的创新在哪里使它们比以前的产品更加优秀？
多年来,我已经在数百个应用程序中编写了数据访问层,持久性组件,甚至我自己的ORM(我的一个"爱好"); 我甚至实现了自己的业务事务管理器(在其他地方讨论了SO).
ORM工具已经在其他平台上存在了很长时间,例如Java,Python等.现在看来,以微软为中心的团队已经发现了一种新的时尚.总的来说,我认为这是一件好事 - 这是探索和理解架构和设计概念的必要步骤,这些概念似乎随着.NET的到来而引入.
一句话:我总是喜欢自己做数据访问,而不是打击一些试图"帮助"我的工具.放弃对命运的控制是绝对不可接受的,数据访问是我应用程序命运的关键部分.一些简单的原则使数据访问非常易于管理.
使用模块化,抽象和封装的基本概念 - 将您的平台的基本数据访问API(例如,ADO.NET)与您自己的层一起包装,从而将抽象级别提升到更接近您的问题空间.不要直接针对该API编码所有数据访问(也在SO上的其他地方讨论过).
严格应用DRY(不要重复自己)原则=重构数据访问代码中的日光.在适当的时候使用代码生成作为重构的方法,但是尽可能地消除对代码生成的需要.通常,代码生成表明您的环境中缺少某些东西 - 语言不足,设计工具限制等.
同时,学习如何使用可用的API,特别是关于性能和健壮性,然后将这些课程纳入您自己的抽象数据访问层.例如,学习在SQL中正确使用参数,而不是将文字值嵌入到SQL字符串中.
最后,请记住,任何成功的应用程序/系统都会遇到性能问题.修复性能问题更多地依赖于设计它们而不仅仅是"调整"实现中的某些东西.该设计工作将影响数据库和应用程序,它们必须同步更改.因此,寻求能够轻松(敏捷)进行此类更改,而不是试图避免不断更改应用程序本身.在某种程度上,这最终意味着能够在不停机的情况下部署变更.如果你没有"设计"它,那就不难做到.
我是一个巨大的ORM倡导者.使用ORM生成代码可以使我的商店在大多数项目中节省大约20-30%.
我们合同开发,所以这是一个巨大的胜利.
Chris Lively提出了一个有趣的观点,即每当查询被触及时都必须进行重新部署.对某些人来说这可能是一个问题,但它根本不会触及我们.我们有针对直接进行生产数据库更改的规则.
此外,你仍然可以依赖传统的sprocs甚至适当的视图...我们不是教条100%ORM,这是肯定的.
自从LLBLGen的免费版本到最新最好的商业产品LLBLGen Pro以来,我一直在ORM火车上工作了很长时间.我认为ORM非常适合许多常见的数据输入输出系统.
这并不是说他们解决了所有问题.它是一种可以在有意义的地方使用的工具.如果您的数据库架构与业务对象的关系相对接近,那么ORM是最好的.
跳起来不是一个潮流,是对真正问题的反应!对象关系映射(ORM)已存在很长时间,它解决了一个真正的问题.
原始面向对象(OO)语言都是关于使用计算机语言模拟现实世界的问题.可以说,如果您真的使用OO语言来构建系统,那么您将使用域驱动设计(DDD)模拟真实世界的问题域.这在逻辑上将您带到一个关注点分离模型,以保持您的DDD清洁和清除数据持久性和应用程序控件的所有混乱.
当您按照DDD模式构建系统并使用Relational数据库进行持久化时,您确实需要一个良好的ORM,否则您将花费太多时间来构建和维护数据库crud(双关语).
ORM是一个老问题,几年前被Object Lens和Top Link等产品解决了.Object Lens是ParkPlace在90年代建造的Smalltalk ORM.Top Link由Object People for Smalltalk构建,然后转换为Java,目前由Oracle使用.Top Link自90年代以来也一直存在.DDD倡导者现在开始清楚地阐明DDD的案例并获得思想共享.因此,ORM必然会成为主流,微软只是像往常一样做出反应.
不,不是每个人都是.
这里是大多数ORM工具(尤其是LINQ to SQL)的房间里头号大屁股大象:
您可以保证,任何与数据相关的更改都需要完全重新部署您的应用程序.
例如,我的日常工作当前可以通过修改现有存储过程并重新部署该一个部分来解决大多数查询问题.使用Linq等人,您的数据查询将移至实际代码中.猜猜那意味着什么？
京公网安备 11010802040832号 | 京ICP备19059560号-6 