Why should business objects must not be also entity objects

[ConstantinPatak]

Hello,

In the CSLA training courses Mr. Lhotka suggest that the bussiness objects must be different from the entity objects (e.g. the EF POCOs) because they serve different purposes. The entity object design goal is to normalize the data and the business object design goal is to normalize the behavior.

What I am trying to do is to use the CSLA with the Entity Framework 6. The Entity Framework 6 gives you the choice to map the tables into different objects and the object into different tables. With this you can achieve both data normalization and behavior normalization. With that in mind is it or is it not good solution to merge together the entity objects (POCOs) and the business object and why?

Thanks in advanced

[hurcane]

Data normalization (in a relational database) and behavior normalization have conflicting goals. It is not usually possible to normalize both things in the same class. David West, in the classic "Object Thinking", coined the term "object relational impedance mismatch" to describe this problem.

Entity Framework can make it easier to deal with this impedance mismatch, but it does not entirely eliminate the problem. A single class works if you are doing a simple "forms over data" entity. Most applications have some of these kinds of forms, but that is not where the business value (i.e. solving complex problems) lies.

[ConstantinPatak]

Thanks for your response hurcane. But can you give me an example where the Entity Framework fails to normalize both data and behavior?

[ajj7060]

Well one example might be is if you have some data, say associated with an order, but you only want your internal operations team to see it and not your customers, if you're using the Order DTO from EF you'll have to add those properties and ensure security so that they aren't accidently used in the website customers use for managing their orders.

You can argue "just be careful, and don't expose those properties to the customer site," but that's easier said than done, and its a communication problem. You're now relying on tribal knowledge for developers to know which properties must not be shown to customers and are for admin use only. Nevermind a business rule one an admin only property that prevents saving the order, but of course the customer can't even access that property to make the change they want to their order.

It's actually a scenario very similar to that which lead me to discover Csla; we were doing exactly that (before ORM frameworks were available on .Net, and people were rolling their own). It was a base class/sub class conflict, where fixing a bug for one use case broke the other due to the tight coupling of the behavior to the shape of the data in the database. I knew there had to be a better way, and learning Csla + the philosophy of design it encourages has helped tremendously.

Also imagine moving a field from one table to another; its no longer a back end change, you've now broken your UI, potentially in multiple places. That might happen anyway, but in many cases if you've done the design right, you don't need to change your UI to accommodate the moving of a field.

And finally, what if you want to load the data from a web service now instead of EF? You have to now change all your BOs to accommodate that, when really you should just be changing the code that they use to load while hiding that change behind the public API of your BO.

[ConstantinPatak]

Hi ajj3085. Thank a lot for you response. I believe it is a little more clear to me now.