2

Planning my architecture for an MVVM application I come to this:

  • MyApp.UI
    • View
  • MyApp.BusinessLayer
    • ViewModel
  • MyApp.DataAccessLayer
    • RepositoryImplEF
  • MyApp.DomainLayer
    • DomainObject
    • RepositoryInterface
  • MyApp.Common
    • Logging
    • Security
    • Utility (contains some reflection method used by many levels)
    • CustomException
  • MyApp.UnitTest

I was inspired by Domain-driven-desing, test-driven-development and onion architecture but not sure to have done all well.

I am not sure of a couple of things:

  1. where to put dependency injection configuration class? In the common project?
  2. where to put BusinessLayer interfaces? in Domain layer?
  3. where to put Common interfaces? in Domain layer? But Common in referenced from domain (for some reflection utilities and for DI if the response to 1. is yes) and circular reference isn't good
Improve this question
1

We have a fairly large MVVM application that I helped design. We have a single project known as the Host. this will be the main executable for the entire applicaton and contains the Bootstrapper for the Dependency Injection.

  • MyApp.Host
    • Bootstrapping
    • Configure container for all dependencies
    • Runs the main application

Also we had separate class libraries for all our interfaces so we would have:

  • MyApp.ViewModels.Interfaces

This will allow your application to have no circular references as it will only be the Host app that needs to know about the relationship between your viewmodels and the interfaces.

Improve this answer
  • Yes, i need a project for the dependecy injection resolution, good suggestion – gt.guybrush Sep 17 '13 at 8:25
  • How you structure domain and data access layer? – gt.guybrush Sep 17 '13 at 8:32
  • We had it much the same as you do. Four primary layers, UI for the Views, PL (Presentation Layer) for the ViewModels, BL(Business Layer) for business logic and models and DA(Data Access Layer) for all data providers which interacted between the database and the business layer. – stuartmclark Sep 17 '13 at 14:26
  • :) Now iam studing the idea of put all interface into domain. Other question, ui speak direclty to DAL and domain or this is make by PL? – gt.guybrush Sep 17 '13 at 14:55
  • the UI should not know about anything really, are you using an MVVM framework to handle interaction between the View and ViewModel? I would recommend Caliburn.Micro if you are not. so the Views shouldn't really know anything except what to display, the ViewMOdels would have an instance of a Business Layer class injected into its constructor and the business layer class would interact with the DAL. In short, only the business layer interacts with DAL nothing else should know about the DAL. and the DAL / BL should know nothing about the View, only the ViewModel interacts with the View. – stuartmclark Sep 19 '13 at 9:26
0

  1. Common is your best bet as the information is independent of the responsibilities the MVVM layers represent.

  2. Yes, domain layer / ViewModel. That area owns the business logic, so it ought to have the interfaces.

  3. Common interfaces for what? Interfaces belong to the layer that owns the responsibility for the action represented by the classes.

The other layers will reference the common layer. The common layer shouldn't need to reference anything within the other layers (otherwise, it wouldn't be common). Think through what the responsibilities are for each component, and you should be able to more easily identify where things belong.

If the challenge is with your DI configuration class(es), then you made need to separate them out. A master configuration class would live within the common layer. Layer specific configuration may need to be created at each layer.

Improve this answer
  • 2 and 3 - Accordind to Onion and orthogonal architecture interface and implementation reside in different layer, so iam asking where put the interfaces of Common project and Business project classes. Putting DI in Common didn't i need to add referenece to every interface and impl of my solution? – gt.guybrush Sep 16 '13 at 14:44
  • @gt.guybrush - Pick an architecture and stick with it. Don't just pick and choose amongst architectures as you think you see fit. Or at least don't do so until you thoroughly understand the architectures that you are using. Your question was specifically scoped to MVVM, which is what my answer is driven by. – user53019 Sep 16 '13 at 15:08
  • My problem is how to put alla toogheter, i have no find two mvvm project with equals architecture from UI to Domain. if i undertand well mvvm concerns only ui and some business logic, but not data access and common services – gt.guybrush Sep 17 '13 at 8:29
  • Found this: stackoverflow.com/questions/15980963/… it's speak of putting all interfaces in domain (core) but i don't understand everything – gt.guybrush Sep 17 '13 at 8:30
0

IoC container initialization is usually located in the bootstrapper. This class is part of your infrastructure/initialization and does not really belong to any "common" thing. Since you don't plan to work with your domain model via messaging/services but using BL/DAL, I would strongly recommend to put IoC related stuff to modules, assuming you use a container that supports modules. This way you can keep your bootstrapper thin and do your registrations per module and modules are located in corresponding projects.

Concerning the BL, the question is what do you plan to put there. If your domain model is anemnic, you will have a huge business "managers" projects with all logic concentrated there. I would not call this part of your domain model. If, at the other hand, your domain model is planned to be a rich model, you will have a bunch of behaviours in your domain classes by definition. The rest of business logic would be separated to complex validations, commands and queries. What you call DAL with repositories are in fact queries. I would prefer trying to implement CQRS.

Improve this answer
  • Iam starting to implement it but i encounter first problem trying to use Caliburn.Mirco as IoC for all application. I create Domain layer with his bootstrapper but don't find a way to start it when running test – gt.guybrush Oct 16 '13 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.