我真的需要看一些关于当前公认的企业应用程序设计范例的优点的诚实,深思熟虑的辩论.
我不相信实体对象应该存在.
实体对象我指的是我们倾向于为我们的应用程序构建的典型事物,如"人","帐户","订单"等.
我目前的设计理念是这样的:
(注意:我还使用Java EE构建了企业应用程序,java人员请用等价替换我的.NET示例)
我不是反OO.我为不同的目的写了很多类,而不是实体.我承认我编写的大部分类都是静态助手类.
我不是在建造玩具.我在谈论跨多台机器部署的大型高容量事务应用程序.Web应用程序,Windows服务,Web服务,b2b交互,您可以为其命名.
我使用过OR Mappers.我写了几个.我使用过Java EE堆栈,CSLA和其他一些等价物.我不仅使用它们,而且还在生产环境中积极开发和维护这些应用程序.
我已经得出了经过实战考验的结论,即实体对象正在阻碍我们,如果没有它们,我们的生活会变得如此简单.
考虑这个简单的例子:你得到一个关于你的应用程序中某个页面不能正常工作的支持调用,可能其中一个字段没有像它应该那样持久化.使用我的模型,分配给发现问题的开发人员正好打开3个文件.ASPX,ASPX.CS和带有存储过程的SQL文件.该问题可能是存储过程调用缺少的参数,需要几分钟才能解决.但是对于任何实体模型,您总是会启动调试器,开始逐步执行代码,最终可能会在Visual Studio中打开15-20个文件.当你走到堆栈底部时,你忘记了你的起点.我们一次只能在头脑中保留这么多东西.软件非常复杂,无需添加任何不必要的图层.
开发复杂性和故障排除只是我抱怨的一个方面.
现在让我们谈谈可扩展性.
开发人员是否意识到每次编写或修改与数据库交互的任何代码时,他们都需要对数据库的确切影响进行彻底的分析？而不仅仅是开发副本,我的意思是模仿生产,所以你可以看到你现在需要的对象的附加列只是使当前的查询计划失效,而在1秒内运行的报告现在需要2分钟,因为您在选择列表中添加了一个列？事实证明,您现在需要的索引是如此之大,以至于DBA将不得不修改文件的物理布局？
如果让人们通过抽象让物理数据存储距离太远,他们就会对需要扩展的应用程序造成严重破坏.
我不是狂热者.我可以确信我是否错了,也许我是,因为Linq对Sql,ADO.NET EF,Hibernate,Java EE等有如此强烈的推动.请通过您的回答思考,如果我遗漏了一些东西我我真的想知道它是什么,为什么我应该改变我的想法.
[编辑]
看起来这个问题突然再次激活,所以现在我们有了新的评论功能,我直接评论了几个答案.感谢回复,我认为这是一个健康的讨论.
我可能应该更清楚我正在谈论企业应用程序.我真的不能评论一个在某人的桌面或移动应用程序上运行的游戏.
有一点我必须在顶部提出以回应几个类似的答案:正交性和关注点分离经常被引用作为实体/ ORM的理由.对我来说,存储过程是我能想到的关注点分离的最好例子.如果您不允许除了通过存储过程之外的所有其他数据库访问,理论上您可以重新设计整个数据模型而不破坏任何代码,只要您维护存储过程的输入和输出即可.它们是按合同编程的完美示例(只要您避免"select*"并记录结果集).
询问那些已经在这个行业工作了很长时间并且使用过长期应用程序的人:在数据库存在的时候,有多少应用程序和UI层已经出现了？当有4个或5个不同的持久层生成SQL来获取数据时,调整和重构数据库有多难？你什么都不能改变!ORM或任何生成SQL的代码都会锁定您的数据库.