ORM似乎是一个快速增长的模型,其优点和缺点都在他们身边.来自Richard Kiessig的超快ASP.NET(http://www.amazon.com/Ultra-Fast-ASP-NET-Build-Ultra-Scalable-Server/dp/1430223839/ref=pd_bxgy_b_text_b):
"我喜欢他们,因为他们允许我非常快速地开发小型的概念验证网站.我可以将大部分的SQL和相关的复杂性放在我需要的地方,并专注于对象,业务逻辑和演示.但是,与此同时,我也不关心它们,因为不幸的是,它们的性能和可扩展性通常非常差,即使它们与一个全面的缓存系统集成(当你意识到正确的时候,它的原因就变得清晰了)配置,SQL Server本身实际上只是一个大数据缓存"
我的问题是:
你对理查德的想法有何评论？你同意他的意见吗？如果没有,请说明原因.
ORM和传统数据库查询最适合的字段是什么？换句话说,你应该在哪里使用ORM,你应该在哪里使用传统的数据库查询:),哪种类型/大小...应用程序你无疑应该选择ORM /传统的数据库查询
提前致谢
我不能同意关于ORM表现不好的常见抱怨.到目前为止,我已经看过很多普通的SQL应用程序.虽然理论上可以编写优化的SQL,但实际上,它们通过编写非优化的业务逻辑来破坏所有的性能提升.
使用纯SQL时,业务逻辑高度耦合到db模型和数据库操作,并且优化取决于业务逻辑.因为没有oo模型,所以无法传递整个对象结构.我已经看到许多应用程序传递主键并一次又一次地从每个层上的数据库中检索数据.我见过在循环中访问数据库的应用程序.等等.问题是:因为业务逻辑已经难以维护,所以没有空间可以进行更多优化.通常,当您尝试重用至少一些代码时,您会认为它并未针对每种情况进行优化.性能因设计而变差.
ORM通常不要求业务逻辑过多关注数据访问.在ORM中实现了一些优化.有缓存和批次的能力.这种自动(和运行时动态)优化并不完美,但它们将业务逻辑与其分离.例如,如果有条件地使用了一段数据,它会根据请求使用延迟加载(恰好一次)加载它.你不需要做任何事情就可以做到这一点.
另一方面,ORM的学习曲线陡峭.除非ORM已被同一团队使用,否则我不会将ORM用于简单的应用程序.
ORM的另一个缺点是(实际上不是ORM本身,而是你将使用关系数据库和对象模型),团队需要在两个世界中都很强大,关系以及oo .
结论:
ORM对于以业务逻辑为中心的应用程序非常强大,其数据结构足够复杂,具有OO模型将是有利的.
ORM通常具有(某种程度上)陡峭的学习曲线.对于小型应用程序,它可能会变得太昂贵.
基于简单数据结构的应用程序,没有太多的逻辑来管理它,很可能更容易和直接用简单的SQL编写.
拥有高水平数据库知识且没有太多oo技术经验的团队通过使用普通的sql更有效率.(当然,根据他们编写的应用程序,建议团队切换焦点)
通过使用ORM,具有高水平知识和唯一基本数据库经验的团队可能更有效率.(同样在这里,根据他们编写的应用程序,建议团队切换焦点)
ORM很老了,至少在Java世界里.ORM的主要问题:
面向对象的模型和关系模型是完全不同的.
SQL是一种基于关系代数访问数据的高级语言,不同于任何OO语言,如C#,Java或Visual Basic.Net.混合这些可以是两个世界中最糟糕的,而不是最好的
有关更多信息,请在网上搜索"对象关系阻抗不匹配"等内容
无论哪种情况,一个好的ORM框架都会为您节省相当多的样板代码.但是你仍然需要知道SQL,如何设置一个好的SQL数据库模型.首先使用SQL创建一个好的数据库模型,然后根据它建立一个OO模型(不是相反)
但是,如果您确实需要使用SQL数据库,则上述操作仅适用.我也建议调查NoSQL运动.像Cassandra,Couch-db这样的东西.谷歌搜索.net解决方案时,我发现了这个stackoverflow问题:https://stackoverflow.com/questions/1777103/what-nosql-solutions-are-out-there-for-net
京公网安备 11010802040832号 | 京ICP备19059560号-6 