The example on the right is from the new MVC Music Store sample, and it show a way of designing software that was quite popular in the end of the previous century and the early part of this century.
In part, it was wildly popular because of the type of infrastructure that was available to build software on. In you consider the time frame, that was the height of COM and the golden age of EJB. Both sets of infrastructure focused on stateless components manipulating “entities” that were just data holders.
The reason why there was such a focus on statelessness? Creating objects used to cost a lot at the time, especially since you needed a reference to those objects across servers, so you really had no better choice than going with this approach.
Why should this style be retired?
Well, let us consider what we have, tight coupling to the environment in which it runs and lot of explicit queries to the database. I could live with either easily, especially since the sample is intended to serve as a guide for beginners.
What really bothers me is that we now have the behavior related to working with our model scattered high and wide. Okay, that isn’t quite fair. Most of the logic in the system reside in the ShoppingCart component. What bothers me is that we have:
By that I mean, we have the controllers directly query the persistent DTOs that we have. This leads to situations such as this:
This is a controller method, I really don’t think that it should be concerned with the type of foreign keys and cascade relations that we have on the database. There is another issue here, that the sharp eyed among you might have noticed, there is no shared unit of work (data context in this case). Each different component is going to access the database through its own data context, meaning that you have multiple ways of getting the same persistent DTO back, through different connections, getting different instances, on the same request.
In short, the problem with component oriented design is that it separate data from behavior and lead to a scattering of the knowledge about the actual data structure and access pattern throughout the application.
I would much rather see behavior moved into the entities (upgrading them from persistent DTOs to actual entities), querying being centralized in a repository and a single unit of work that applies to the entire request.