为什么我们需要实体对象？ [英] Why do we need entity objects?
问题描述
我真的需要对目前接受的企业应用程序 设计范例的优点进行一些诚实，周到的辩论。
我不相信实体对象应该存在。
通过实体对象我的意思是我们倾向于为我们的应用程序构建的典型的东西，如Person 帐户，订单等。
我目前的设计理念是：
- 必须通过存储过程完成所有数据库访问。
- 每当需要数据时，调用存储过程并遍历SqlDataReader或DataTable中的行
（注意：我也用Java EE构建了企业应用程序，java人员请用equivalent替换我的.NET示例）
我不是反OO。我写了很多类用于不同的目的，只是不是实体。我会承认，我写的很大一部分类是静态助手类。
我不是建立玩具。我在谈论部署在多个机器上的大型，大容量事务应用程序。 Web应用程序，Windows服务，Web服务，b2b交互，你叫它。
我使用了OR Mappers。我写了几个。我已经使用Java EE堆栈，CSLA和一些其他等同物。我已经不仅使用它们，而且在生产环境中积极开发和维护这些应用程序。
我已经得到了经验证的结论，实体对象正在我们的方式，
考虑这个简单的例子：您在应用程序中获取关于某个页面的支持电话这是不能正常工作，也许一个字段不是持久存在，因为它应该是。使用我的模型，分配到查找问题的开发人员打开正好3个文件。一个ASPX，一个ASPX.CS和一个带有存储过程的SQL文件。该问题可能是存储过程调用的缺少参数，需要几分钟时间来解决。但是对于任何实体模型，你总是启动调试器，开始逐步执行代码，最终可能会有15-20个文件在Visual Studio中打开。当你下到堆栈的底部，你忘了你在哪里开始。我们一次只能在头脑中保留这么多的东西。软件非常复杂，没有添加任何不必要的层。
开发复杂性和故障排除只是我的一个方面。
现在让我们谈谈可扩展性。
开发人员意识到，每当他们编写或修改任何与数据库交互的代码时，他们需要做一个彻底的分析对数据库的确切影响？而不只是开发副本，我的意思是一个模仿的生产，所以你可以看到，你现在需要的对象的附加列只是使当前的查询计划失效，并且运行1秒的报告现在将需要2分钟，只是因为您向选择列表中添加了单个列？事实证明，你现在需要的索引是如此之大，以至于DBA将不得不修改你的文件的物理布局？
如果你让人太远离带有抽象的物理数据存储，他们将使用需要扩展的应用程序创建破坏。
我不是一个狂热者。我可以相信，如果我错了，也许我是，因为有如此强大的推动Linq到Sql，ADO.NET EF，Hibernate，Java EE等。请考虑你的回答，如果我错过了一些东西
p>看来这个问题突然再次激活，所以现在我们有了新的注释功能，我直接评论了几个答案。感谢您的回复，我认为这是一个健康的讨论。
我可能应该更清楚，我在谈论企业应用程序。我真的不能评论，说，一个运行在某人的桌面上的游戏，或移动应用程序。
我必须把这里放在顶部对几个类似答案的响应：正交性和关注的分离经常被引为作为实体/ ORM的原因。对我来说，存储的程序是我可以想到的关注的分离的最好的例子。如果禁止对数据库的所有其他访问，除非通过存储过程，您可以在理论上重新设计整个数据模型，并且不破坏任何代码，只要您维护存储过程的输入和输出。他们是合同编程的一个完美的例子（只要你避免select *并记录结果集）。
问一个谁在行业中很长时间，并与长寿命的应用程序：有多少应用程序和UI层已经走过，而数据库已经存在？当有4或5个不同的持久层生成SQL以获取数据时，调整和重构数据库有多难？你不能改变任何东西！ ORM或任何生成SQL的代码 锁定数据库。
p>我认为这归功于应用程序的逻辑有多复杂，以及您实现它的地方。如果所有的逻辑都在存储过程中，并且所有的应用程序都调用这些过程并显示结果，那么开发实体对象的确是浪费时间。但是对于一个应用程序，其中对象与另一个对象具有丰富的交互，并且数据库只是一个持久化机制，可以有价值的有这些对象。
说没有一个适合所有的答案。开发人员确实需要注意，有时，尝试过于OO可能会导致更多的问题，而不是解决。
I really need to see some honest, thoughtful debate on the merits of the currently accepted enterprise application design paradigm.
I am not convinced that entity objects should exist.
By entity objects I mean the typical things we tend to build for our applications, like "Person", "Account", "Order", etc.
My current design philosophy is this:
- All database access must be accomplished via stored procedures.
- Whenever you need data, call a stored procedure and iterate over a SqlDataReader or the rows in a DataTable
(Note: I have also built enterprise applications with Java EE, java folks please substitute the equvalent for my .NET examples)
I am not anti-OO. I write lots of classes for different purposes, just not entities. I will admit that a large portion of the classes I write are static helper classes.
I am not building toys. I'm talking about large, high volume transactional applications deployed across multiple machines. Web applications, windows services, web services, b2b interaction, you name it.
I have used OR Mappers. I have written a few. I have used the Java EE stack, CSLA, and a few other equivalents. I have not only used them but actively developed and maintained these applications in production environments.
I have come to the battle-tested conclusion that entity objects are getting in our way, and our lives would be so much easier without them.
Consider this simple example: you get a support call about a certain page in your application that is not working correctly, maybe one of the fields is not being persisted like it should be. With my model, the developer assigned to find the problem opens exactly 3 files. An ASPX, an ASPX.CS and a SQL file with the stored procedure. The problem, which might be a missing parameter to the stored procedure call, takes minutes to solve. But with any entity model, you will invariably fire up the debugger, start stepping through code, and you may end up with 15-20 files open in Visual Studio. By the time you step down to the bottom of the stack, you forgot where you started. We can only keep so many things in our heads at one time. Software is incredibly complex without adding any unnecessary layers.
Development complexity and troubleshooting are just one side of my gripe.
Now let's talk about scalability.
Do developers realize that each and every time they write or modify any code that interacts with the database, they need to do a throrough analysis of the exact impact on the database? And not just the development copy, I mean a mimic of production, so you can see that the additional column you now require for your object just invalidated the current query plan and a report that was running in 1 second will now take 2 minutes, just because you added a single column to the select list? And it turns out that the index you now require is so big that the DBA is going to have to modify the physical layout of your files?
If you let people get too far away from the physical data store with an abstraction, they will create havoc with an application that needs to scale.
I am not a zealot. I can be convinced if I am wrong, and maybe I am, since there is such a strong push towards Linq to Sql, ADO.NET EF, Hibernate, Java EE, etc. Please think through your responses, if I am missing something I really want to know what it is, and why I should change my thinking.
[Edit]
It looks like this question is suddenly active again, so now that we have the new comment feature I have commented directly on several answers. Thanks for the replies, I think this is a healthy discussion.
I probably should have been more clear that I am talking about enterprise applications. I really can't comment on, say, a game that's running on someone's desktop, or a mobile app.
One thing I have to put up here at the top in response to several similar answers: orthogonality and separation of concerns often get cited as reasons to go entity/ORM. Stored procedures, to me, are the best example of separation of concerns that I can think of. If you disallow all other access to the database, other than via stored procedures, you could in theory redesign your entire data model and not break any code, so long as you maintained the inputs and outputs of the stored procedures. They are a perfect example of programming by contract (just so long as you avoid "select *" and document the result sets).
Ask someone who's been in the industry for a long time and has worked with long-lived applications: how many application and UI layers have come and gone while a database has lived on? How hard is it to tune and refactor a database when there are 4 or 5 different persistence layers generating SQL to get at the data? You can't change anything! ORMs or any code that generates SQL lock your database in stone.
I think it comes down to how complicated the "logic" of the application is, and where you have implemented it. If all your logic is in stored procedures, and all your application does is call those procedures and display the results, then developing entity objects is indeed a waste of time. But for an application where the objects have rich interactions with one another, and the database is just a persistence mechanism, there can be value to having those objects.
So, I'd say there is no one-size-fits-all answer. Developers do need to be aware that, sometimes, trying to be too OO can cause more problems than it solves.
这篇关于为什么我们需要实体对象？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
