jeudi 29 janvier 2015

Repository pattern in DDD, MVC [on hold]

Now this is the first time I am really thinking about design patterns and doing things properly and the most modern way. I have come across a pattern named domain driven design. From my understanding it is simply designing the business logic layer in a more ‘domain-oriented’ way. Although I have worked on massive projects but unfortunately most of them were designed poorly and the separation of logic was not done properly. We have 3 layered applications here but they are very leaky. I am trying to change things here but with no one to guide, I am really confused!


The project is developing an MVC app along with an API that will be serving live data to lot of interested parties around the World. MVC app will be simple and will allow users to register for usage of Web API. Web API is the real thing, it would be an interface for the rest of the World for massive amounts of valuable data that we have. Some examples of the methods I am going to expose are:



  1. Bool VerifyLoginDetails (string username, string pwd )

  2. List GetPlayerByNation (string NationCode, Datetime StartRange, Datetime EndRange )

  3. Player GetPlayerDetails ( int PlayerId )


There are several designs I am thinking of for web api:


Design 1


DAL: Normal data access methods, caching, Repository methods implementation


BLL: Repository interface, Business methods (logic & validation), Business objects/entities


Presentation: MVC app


Design 2


DAL: Normal data access methods, caching


Domain Layer: Repository methods implementation, Repository interface, Business (domain) objects/entities


BLL: Business methods (logic & validation)


Presentation: MVC app


Which approach do you guys think is better? Would you make any changes to above?



  • I am using the repository pattern because we intend to change our database system from sql to no-sql one in few years! In order to make the switch as painless as possible, repository pattern is being used.

  • I am not using DTO’s here. I cant see any use of them since I think I can pass around Business objects from one layer to another. Is there any con to it given the nature of methods mentioned above.


Thank you very much!


Aucun commentaire:

Enregistrer un commentaire