C# – MVVM application architecture, where to put dependency injection configuration class, BusinessLayer and Common interfaces

Architecturecdependency-injectiondomain-driven-designmvvm

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:

where to put dependency injection configuration class? In the common project?
where to put BusinessLayer interfaces? in Domain layer?
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

Best Answer

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.

Related Solutions

Architecture – Software Design Idea for multi tier architecture

I'll be very general so sorry if it is nothing new for you, I know that's boring:

adding a layer adds flexibility but costs some performance
adding a layer does not improve scalability (it has to be addressed separately at every layer that creates bottleneck)

I do not know your stack, but similar applications usually consists of database, middleware (domain object with their mapping to database, business logic) and frontend (web interface for humans).

Depending on situation some layers can be merged (embedded database, business logic and frontend as single web app) - that is OK as long as you keep the dependencies clean (no cycles) and you already know where to cut to divide the siamese twins when it becomes necessary.

Dependency Injection – Abstract Factory Patterns in C#

It seems you're struggling trying to create objects that create objects... wouldn't you be better off just creating objects ?

Ninject allows you to do so in a very simple way :

// Ninject module
Bind<IRepository<SomeEntity>>().To<SomeEntityRepository>();

// injected class
public class SomeService
{
  public SomeService(IRepository<SomeEntity> repository)
  {
    // ...
  }
}

// get instance of injected class
var someService = kernel.Get<SomeService>();

I can't see the benefit of an abstract factory in addition to an IoC container when you're creating objects based on basic, compile-time-known constraints such as in your SomeViewFactory and SomeRepositoryFactory examples.

The dynamic nature of SomeFunctionalityFactory would be more debatable, but when you think of it, do you really need to instantiate an object with the built-in notion that it will never be able to be used by the current user ? Wouldn't it make more sense to have the object evaluate user authorization when the functionality is called ?

Best Answer

Related Solutions

Architecture – Software Design Idea for multi tier architecture

Dependency Injection – Abstract Factory Patterns in C#

Related Topic