6

I’m building a project that currently has 3 assemblies:

  • UI
  • Core (Services & Models, Utilities)
  • Repositories (Linq2SQL)

Dependencies are

  • UI -> Core
  • Core -> Repositories.

I’d like Services and Models to be in their own assemblies and end up with something that’s built around the Models i.e.:

  • UI ->Models, Services
  • Services -> Models, Repositories
  • Repositories -> Models
  • Models

The system I’m building is basically a website CMS so I’ll have a model for a web page (PageModel) which has a collection of child web pages. PageModel can call methods in a service (PageService) to populate its child pages but in the new design that can’t happen because the Models assembly necessarily knows nothing of the services assembly.

I’ve considered some of the ideas in the Onion Architecture (namely dependency injection) to solve this, but it seems that a more elegant /obvious solution might be available.

Do I need to introduce another layer of Model? View Models? I think what I’m calling Models are Domain Models... I may very well be wrong! Services would then be Domain Services?

So my solution would be:

  • UI -> Services, ViewModels, Models
  • ViewModels -> Services, Models
  • Services -> Repositories, Models
  • Repositories -> Models
  • Models

In this example I imagine my PageViewModel would extend PageModel and use the PageService to fetch it’s child pages..

Any suggestions appreciated. Also any pointers on what these layers of models are usually called? Am I talking about DTO Models rather than Domain Models here? And Domain Models rather than View Models? It seems like what I'm proposing to use the View Models for isn't really the job of a View Model..

Thanks

EDIT:

Something I hadn't mentioned originally is that my Domain Models aren't basic translations of single database entities like you tend to see in most tutorials. A domain model can contain data fields that come from several related database tables.

So would it be worth having a set of Models purely to encapsulate the the data in the Domain - without any methods/properties that fetched related objects or saved the object back to the DB etc? - Data Transfer Objects.

From looking at a couple of scribbled diagrams this would mean having a set of mappers in the domain layer (which seems wrong..) to translate DTO models to Domain Models and back. The project would become built around the DTO models rather than the domain models but given what's encapsulated by the DTOs I don't see that being a problem.

For anyone who's interested, the proposed dependency structure would be like so:

  • UI -> Services, Domain Models
  • Services -> Repositories, Domain Models, DTO Models
  • Domain Models -> Repositories, DTO Models
  • Mappers -> Domain Models, DTO Models
  • Repositories -> DTO Models
  • DTO Models (no dependencies)

It's a bit of a mess! And all just because I want my PageModel to be able to fetch its own child PageModels.. It's looking like having a go at dependency injection might not be such a bad plan.

Thanks to the guys who've replied. You've given me loads to think about.

Improve this question

3 Answers 3

Reset to default
2

You can accomplish this just fine with the onion architecture. I'll have for example: UI, Domain, Data Access, Services

UI Services Data Access Domain (contains view models as well)

UI can access any one. Services, only data access and domain. Data access - only domain.

My repository interfaces are in the domain project, and they are implemented in the data access project. I also keep other interfaces in the domain project (IContext, IUnitOfWork, etc) so I have one central place and not spreading too many interfaces between projects.

DTOs would be used simply for transferring between layers, if you deem appropriate. There's no reason to me you can't pass a domain model from a data layer on up, some choose to only use DTOs here. I'll do the mapping in the UI layer (ex MVC controller) to a ViewModel since I can make use of AoP to do it for me ([AutoMap()] attribute )

Just remember that your models should not contain any persistence logic at all.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thanks Adam. Putting the repository interfaces in the Domain seems a neat way of keeping everything centred around the domain. On the persistence point, my Domain Models have convenience methods for Save() which just call the Save() method in the relevant repository. Would you consider that to be persistence logic and therefore bad practice?
ya, they should know nothing about it. Pass the entity to your repository and let it be the single place to handle everything. this then adapts nicely to a unit of work pattern, as the repositories can be refactored to now actually save it to a collection, and the unit of work implementation saves that collection to the db in one transaction. Your services, rather than calling Save() on the models, instead just know to call the repository implementation, which should be injected into your controller or repository. This lends itself nicely to testing/mocking/etc.
2

I think it is pretty typical of any "real world" application to store data differently than is displayed on the screen. I think you are on the right track, with having 2 seperate "models". I usually end up calling them:

  • ViewModels - map to what is displayed on the screen, what the views want.
  • DataModels - map to the DB, what the persistence layer (ORM) wants.

Sometimes the DataModels are called Entities especially when talking about Entity Framework as a data access layer, or Data Transfer Objects (DTOs).

Usually there is some set of "translators" to map from the view to the data models too, or sometimes AutoMapper can be used.

Of course if what you are displaying is close enough to your data structure, there is no harm is passing all the persistence / data models to the Views, but I like to keep them separate too.

Improve this answer

1 Comment

Thanks. I'm starting to wonder about the DTO Models. My models aren't necessarily simple mappings from single database tables. I might have to answer my own post to explain that properly though..
2

I’ve considered some of the ideas in the Onion Architecture (namely dependency injection) to solve this, but it seems that a more elegant /obvious solution might be available.

Once you get the hang of using Dependency Injection correctly, it's really a very elegant/obvious solution.

I'd suggest a dependency structure like this:

  • UI
    • Controllers -> Services, Models, ViewModels
    • Views -> ViewModels
    • ViewModels (no dependencies)
  • Services -> Repositories, Models
  • Repositories -> Models
  • Models

This is pretty close to what you had before, but your ViewModels are a part of your UI project and have no dependencies at all. They should just be simple classes that represent what you want to show to the user.

It's the Controller's job to:

  • Invoke the services to get the Models,
  • Translate the models into ViewModels, and
  • Invoke the View code

Views should not require any information that isn't provided by the ViewModels.

Improve this answer

2 Comments

Thanks. I think Dependency Injection is starting to look like the way to go. The project is already pretty complex though (by my standards..) and implementing DI might be quite a challenge..
@Giles: DI has a tendency to make you follow good design patterns. Since you haven't been using it all along, there might be some pain trying to make your code follow the patterns it should have been using all along. But if you do it right, DI should actually help you simplify things quite a bit. Best of luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.