Microsoft.Practices.ServiceLocation and multiple operations

Jun 9, 2011 at 11:51 AM

Hi i would try to explain as briefly my dude

now in the web layer you use Using calling a handler in the domain model, and the operation against the data model is done per this request; for exmple you update a vehicle and from the web layer you call Using<UpdateVehicle> and this handler uses the Vehicle model and the repository for Vehicle.

With this new approach i found that is clear when the application is simple as this but imagine for example this case.

You, for example, update a user with their own address, with a view that is composed with a partial vehicle form and a partial address form, the user controller update method call Using<UpdateUser>.execute() and Using<UpdateAddress>.execute(). The first Execute method makes some modelToEntity transformation without knowledge of the relationship of the address entity "attached to it", loosing the entityFramework context ability to maintain this "automatically"and let you have a "transaction" point of view.

To avoid this or you should create different Execute methods for each kind of web form taking care of the relationship having only one Using call in the controller, or you should create different models at the domain model that have a direct relationship with the models you work to have, again, only one call from the controller, or there is another solution to have not so huge number of handlers?



Jun 14, 2011 at 6:12 PM

I recommend having no more than one handler invoked per controller action. In Mileage Stats, we have a couple of actions that invoked multiple handlers. In future updates we'd like to consolidate those handlers specifically for the reason you list.

Another possible improvement, and this is a somewhat indirect answer to your question, is to move away from the service location pattern (hidden inside the Using<Handler> call) and replace it with a message bus. Instead of invoking a handler directly, we'd simply publish a message on the bus and then let Unity find and invoke the appropriate handler. An example of a message would be one of the existing form models.

Ultimately, if you follow this approach you will end up with a lot of handlers. However, the should be small. discrete, well defined handlers and reading over them should be like reading a list of features for the application. In many ways, these handlers are the domain model. Specifically, they are the verbs (or the behavior) of the domain model.

Let me know if this answers your question.


Jun 17, 2011 at 12:27 PM

Thank you for the answer,

sorry to answer so late, but i was thinking about the next matter.

the issue is how to keep the page developers happy, i mean, many developers are using webforms with controls and so one, and all this are using EntityDatasource or ObjectDataSource Objects to access the service layer, so i was trying to find a way using Julie Lermans blogs and how to connect the service layer and handlers to this. Remember when you use ObjectDatasource you need a not parameter constructor and some struct return type methods for this to work. So my understanding was to create another layer of classes to accomply this, but to be honest i´m a "little bit lost". Could you point me to the right dirrecction? some URLs? or some example?