0

I am having an architecture issue, and I hope someone can point me in the right direction. My problem is: handling DTOs with one-to-many or many-to-many relationships.

I have 5 projects and they should mostly depending to the next one respectively.

  1. Service Layer : connect domain layer to outside world
  2. Domain : Entity, Value Object and so on, Heart of the sw
  3. DTO : Mapper - convert database row to domain object
  4. Repository : CRUD operations
  5. DAL : Using EF Code first approach to create database tables

But i cannot figure out how they should be referred with each other. I have tried few approach and end up with circular reference. Any suggestions are welcome.

MJK
  • 3,434
  • 3
  • 32
  • 55

2 Answers2

1

Here is what I would do with what you've described:

                      Common (shared logic, utility)
                                    |
                      Model (Business objects, pocos)
                                    |
     DAL (Entity Framework -- DbContext definition of Model, migrations etc)
                                    |
            Repository (CRUD implementation using DAL context(s))
                                    |
     Service Layer (Implementation of business logic, using repositories)
DTO Mappers (Translation of business objects to client consumables using repos)
                                    |
          Any API or outward facing interface (webapi, signalr, wcf, mvc)

Usually you use DI to manage these dependencies with some sort of lifetime scope (http request): API -> Service -> Mappers -> Repositories -> DAL.

In my experience I've used the "service" layer to perform unit-of-work operations -- eg. Using the Repository's methods that implement complex and simple queries -> Do business logic -> End UoW -> Return mapped business objects as dto.

Your entity model should be shared throughout. Here are a few resources that might help you develop the architecture right for your application(s)

link & link

Hope this helps!

calebboyd
  • 5,744
  • 2
  • 22
  • 32
  • Thanks a lot for taking your time for answering this. I will try this and let you know. I have few questions in my mind, Why the service layer should be depended on repositories? What are the cons if this layer directly depend on Model? And can you please give me an example of a class and the linked table..... Thanks in advance – MJK Apr 27 '14 at 15:56
  • Yeah, No problem, Can you elaborate on what you mean by an "example of a class and the linked table"? – calebboyd Apr 28 '14 at 00:12
  • Thanks for those links. I can see your point. Basically, my domain will contain all the business logics. I am trying to avoid adding business logics inside repo or sl. Not sure, is it possible at all or not. Right now, I am having difficulties to transfer row information from DAL to domain model. – MJK Apr 28 '14 at 08:02
0

The Domain layer is at the core of your system, as a general rule it shouldn't depend on other modules - i.e. it should be unaware of how domain entities are persisted, presented to the user, communicated to external systems, etc.

The Onion Architecture is a good starting place for a DDD approach.

When faced with a circular reference problem, ask yourself which module is closer to the center of the onion - which one is essential to your domain and which one is a peripheral detail. If module A has to use something in module B which is further away from the center, make it depend on an abstraction of it instead. Declare the abstraction in module A but implement it in module B and inject it at runtime (see Dependency Inversion principle).

Events can also be used to achieve dependency inversion and help a great deal in decoupling your modules.

guillaume31
  • 13,738
  • 1
  • 32
  • 51