Models in different layers

Apr 17, 2013 at 3:19 PM
In Project silk there are Models in MileageStats.Model and also in the Business layer MileageStats.Domain.
Does anyone know why there is a class User in both Projects, the only difference is that User in MileageStats.Domain has attributes on it?

There is also a Reminder class in MileageStats.Model and a ReminderModel in MileageStats.Domain.

What is the Point of having it like this?
I guess I'm asking what's the use of MileageStats.Model Project? If the User model is updated with an additional property you need to add it on two places.
Developer
Apr 17, 2013 at 8:30 PM
Hi,

Based on my understanding, the models located at MileageStats.Model are simple models representing the entities of the data base, and are used to retrieve and store the data in it thought Entity Framework. Meanwhile, the models located at MileageStats.Domain are the ones used by the controllers and views in the application, which also implement logic regarding the data they contain, like validation, etc. The application transforms one model into the other and backwards when passing information between layers (for example, the User model is converted in the UserService class.)

With that being said, I believe this architecture was implemented mostly based on a design decision, like separating the validation logic from the data access layer or decoupling the controllers / views from the underlying data base schema (while the models in MileageStats.Model can be mapped to the data base, this does not apply to some models in MileageStats.Domain.)

However, design decisions are often different for each application, so this design is not a must for every scenario.

I hope this helps,

Damian Cherubini
http://blogs.southworks.net/dcherubini
Apr 19, 2013 at 6:51 PM
Thanks for answering.

I have one more question regarding Project silk.

The domain Project includes handlers but also Service-classes. What is it that separates a Handler from a Service?
Developer
Apr 22, 2013 at 7:03 PM
Hi,

The documentation describes the handlers in the domain project as " a set of classes that implement the core behavior of the application ," where each handler is in charge of performing only one specific action. The controllers in the application delegate the logic of interacting with the domain layer to those handlers. Based on my understanding, the difference with the services is that they seem to be used only to obtain information from the domain without modifying it.

I believe you can find more information about the Domain layer implemented in Mileage Stats, in the following section of the documentation, where the handlers and models it uses are described:
I hope this helps,

Damian Cherubini
http://blogs.southworks.net/dcherubini
Sep 27, 2014 at 6:44 PM
DCherubini wrote:
Hi,

The documentation describes the handlers in the domain project as " a set of classes that implement the core behavior of the application ," where each handler is in charge of performing only one specific action. The controllers in the application delegate the logic of interacting with the domain layer to those handlers. Based on my understanding, the difference with the services is that they seem to be used only to obtain information from the domain without modifying it.
They have handlers that actually modifying domain, e.g. AddFillupToVehicle, CreateVehicle and DeleteVehicle etc.
But I see that one handler never executes any other handler, so they are really independent from each other.
So it looks like that it will be better to move business logic to Services, e.g. UserServices when one handler should execute another one. For example I see that in UserServices they have method GetOrCreateUser which uses GetUserByClaimedIdentifier or CreateUser methods from UserServices.

That's how I see it. Thoughts?
Thanks!