Why do we need entity objects? [closed]

Answer 1

I would also like to add to Dan's answer that separating both models could enable your application to be run on different database servers or even database models.

Answer 2

What if you need to scale your app by load balancing more than one web server? You could install the full app on all web servers, but a better solution is to have the web servers talk to an application server.

But if there aren't any entity objects, they won't have very much to talk about.

I'm not saying that you shouldn't write monoliths if its a simple, internal, short life application. But as soon as it gets moderately complex, or it should last a significant amount of time, you really need to think about a good design.

This saves time when it comes to maintaining it.

By splitting application logic from presentation logic and data access, and by passing DTOs between them, you decouple them. Allowing them to change independently.

Answer 3

I found your question really interesting.
Usually I need entities objects to encapsulate the business logic of an application. It would be really complicated and inadequate to push this logic into the data layer.
What would you do to avoid these entities objects? What solution do you have in mind?

Answer 4

Entity Objects can facilitate cacheing on the application layer. Good luck caching a datareader.

Answer 5

Not a lot of time at the moment, but just off the top of my head...

The entity model lets you give a consistent interface to the database (and other possible systems) even beyond what a stored procedure interface can do. By using enterprise-wide business models you can make sure that all applications affect the data consistently which is a VERY important thing. Otherwise you end up with bad data, which is just plain evil.

If you only have one application then you don't really have an "enterprise" system, regardless of how big that application or your data are. In that case you can use an approach similar to what you talk about. Just be aware of the work that will be needed if you decide to grow your systems in the future.

Here are a few things that you should keep in mind (IMO) though:

1. Generated SQL code is bad (exceptions to follow). Sorry, I know that a lot of people think that it's a huge time saver, but I've never found a system that could generate more efficient code than what I could write and often the code is just plain horrible. You also often end up generating a ton of SQL code that never gets used. The exception here is very simple patterns, like maybe lookup tables. A lot of people get carried away on it though.
2. Entities <> Tables (or even logical data model entities necessarily). A data model often has data rules that should be enforced as closely to the database as possible which can include rules around how table rows relate to each other or other similar rules that are too complex for declarative RI. These should be handled in stored procedures. If all of your stored procedures are simple CRUD procs, you can't do that. On top of that, the CRUD model usually creates performance issues because it doesn't minimize round trips across the network to the database. That's often the biggest bottleneck in an enterprise application.

Answer 6

Interesting question. A couple thoughts:

1. How would you unit test if all of your business logic was in your database?
2. Wouldn't changes to your database structure, specifically ones that affect several pages in your app, be a major hassle to change throughout the app?