S
shapper
Hello,
I am implementing DDD (Domain Driven Design) with ASP.NET MVC / WPF,
Entity Framework and Fluent Validation in ASP.NET 3.5 SP1 and VS 2008
SP1
My current implementation has the following layers:
1. MyApp.Infrastructure
In Infrastructure I have two namespaces: Entities (Or should I call
it models?) and Repositories.
Entities will, basically, contain the Entity Framework.
Repositories will contain the Repositories Interfaces.
2. MyApp.Domain
In Domain I implement the Repositories defined in the Interfaces on
Infrastructure.
3. MyApp.Application
In Application I will have three namespaces:
A) Models
I ) Define new Entities that are more adapted to the Views. Why
and How?
In Product views the validation will be basically the same
so I will have one ProductValidator.
In Login, SignIn, Edit Profile views I will have different
validators. So I will create AccountLogin, AccountSignIn,
AccountEditProfile Entities.
This Entities will wrap Infrastructure User, Profile, Role
entities and there will be AccountLoginValidator,
AccountSignValidator, etc.
II ) Define the ViewModels to be used by the UI. Why?
Because a View can needs more then an Entity Product. It
might need a Page Title, A List of Products. So ProductViewModel will
be class that wraps all that;
So I will have: ProductViewModel, AccountSignInModel, etc;
B) Services
Here I will have services like MailService to send emails,
Twiiter services to send Tweets, FileService to save files and so
on ...
C) Validation
Here I will have all the Fluent validators for entities defined
in Infrastructure and used as they are: ProductValidator for Product
Or Fluent validators for entities defined in Application (see
A): AccounLoginValidator for AccountLogin, AccountSignInValidator for
AccountSignIn
This is why I am keeping the Fluent Validators here and not in
Domain Layer.
4. MyApp.Presentation (The MVC application)
Here I will have the usual MVC components like Controllers, Views,
etc. (I will not have a Model folder)
I will also have a Binders folders for my custom binders like:
ProductBinder, AccountSignInBinder, etc.
On this Binders I will call the Fluent Validators for the entity I
am binding.
The different layers related as follows:
* Infrastructure is the base.
* Domain communicate with Infrastructure to create, update,
delete, etc entities from the database using the repository pattern.
I am trying to implement the UnitOfWork pattern but to be
honest I am not sure if this is possible in ASP.NET 3.5 SP1:
http://blogs.msdn.com/adonet/archiv...-work-patterns-with-entity-framework-4-0.aspx
* Application communicate with Domain repositories and with
external API's like Twiiter, Amazon, etc.
* Presentation will communicate with Application services and it
will use its ViewModels, reshapped models (AccountLogin) and Fluent
Validators.
It also communicates with Domain to use the Repositories.
In case of a WPF application what changes is the presentation layer
becomes the WPF application instead of the MVC application web site.
This said, any suggestion or critic is welcome.
I hope I explained it well.
Thank You,
Miguel
I am implementing DDD (Domain Driven Design) with ASP.NET MVC / WPF,
Entity Framework and Fluent Validation in ASP.NET 3.5 SP1 and VS 2008
SP1
My current implementation has the following layers:
1. MyApp.Infrastructure
In Infrastructure I have two namespaces: Entities (Or should I call
it models?) and Repositories.
Entities will, basically, contain the Entity Framework.
Repositories will contain the Repositories Interfaces.
2. MyApp.Domain
In Domain I implement the Repositories defined in the Interfaces on
Infrastructure.
3. MyApp.Application
In Application I will have three namespaces:
A) Models
I ) Define new Entities that are more adapted to the Views. Why
and How?
In Product views the validation will be basically the same
so I will have one ProductValidator.
In Login, SignIn, Edit Profile views I will have different
validators. So I will create AccountLogin, AccountSignIn,
AccountEditProfile Entities.
This Entities will wrap Infrastructure User, Profile, Role
entities and there will be AccountLoginValidator,
AccountSignValidator, etc.
II ) Define the ViewModels to be used by the UI. Why?
Because a View can needs more then an Entity Product. It
might need a Page Title, A List of Products. So ProductViewModel will
be class that wraps all that;
So I will have: ProductViewModel, AccountSignInModel, etc;
B) Services
Here I will have services like MailService to send emails,
Twiiter services to send Tweets, FileService to save files and so
on ...
C) Validation
Here I will have all the Fluent validators for entities defined
in Infrastructure and used as they are: ProductValidator for Product
Or Fluent validators for entities defined in Application (see
A): AccounLoginValidator for AccountLogin, AccountSignInValidator for
AccountSignIn
This is why I am keeping the Fluent Validators here and not in
Domain Layer.
4. MyApp.Presentation (The MVC application)
Here I will have the usual MVC components like Controllers, Views,
etc. (I will not have a Model folder)
I will also have a Binders folders for my custom binders like:
ProductBinder, AccountSignInBinder, etc.
On this Binders I will call the Fluent Validators for the entity I
am binding.
The different layers related as follows:
* Infrastructure is the base.
* Domain communicate with Infrastructure to create, update,
delete, etc entities from the database using the repository pattern.
I am trying to implement the UnitOfWork pattern but to be
honest I am not sure if this is possible in ASP.NET 3.5 SP1:
http://blogs.msdn.com/adonet/archiv...-work-patterns-with-entity-framework-4-0.aspx
* Application communicate with Domain repositories and with
external API's like Twiiter, Amazon, etc.
* Presentation will communicate with Application services and it
will use its ViewModels, reshapped models (AccountLogin) and Fluent
Validators.
It also communicates with Domain to use the Repositories.
In case of a WPF application what changes is the presentation layer
becomes the WPF application instead of the MVC application web site.
This said, any suggestion or critic is welcome.
I hope I explained it well.
Thank You,
Miguel