3

I was reading about ASP.NET Core features and I decide to transfer my current solution ( MVC 5 ) to MVC 6 but I got a little bit confused regarding integrated DI. Currently I have this architecture

Current architecture

CemaManager ( representative layer ) has reference to Helpers, Resource, ViewModel and BLL. Bll has reference to ViewModel, Database and DLL. Dll has reference to Database.

Typical N-tier architecture using DI and Repository pattern.

When I investigate MVC6 there is startup.cs where DI initialize. That means if I want to separate BLL and DAL they will have all reference to MVC6 and all logic will go thru that layer? By the time It's gonna be heavy and hard to maintain and scale or am I wrong?

Is there any way to export startup.cs or DI method to another layer? Maybe somebody know any articles to read or examples?

Daniil T.
  • 1,145
  • 2
  • 13
  • 33
  • Why would they have to reference anything regarding to MVC6? You just instantiate things as previously and the framework will handle the rest. – Sami Kuhmonen Jul 19 '16 at 13:44
  • 2
    see this similar question http://stackoverflow.com/questions/34910589/is-there-a-way-to-have-asp-net-5-dependency-injection-resolve-a-dbcontext-withou/34910859#34910859 – Joe Audette Jul 19 '16 at 13:48
  • It would be nice to use integrated MVC DI. I could use Unity DI as I used in earlier solution. But my goal is to try achieve same result with MVC DI. "Why would they have to reference anything regarding to MVC6?" Because in another case MVC DI won't see neither BLL nor DAL classes. – Daniil T. Jul 19 '16 at 13:48
  • you don't have to reference mvc in business or data layer, ViewModel is concept for MVC but it is not the same as models in your business layer, generally you would retrieve business layer objects ina controller and use it to populate a ViewModel. – Joe Audette Jul 19 '16 at 13:51
  • 1
    another similar question for how to keep data access code out of the UI/mvc code http://stackoverflow.com/questions/38356990/connectionstring-from-appsettings-json-in-data-tier-with-entity-framework-core/38360204#38360204 – Joe Audette Jul 19 '16 at 13:52
  • I think you have something backwards. Of course your main MVC project will reference those assemblies, but those assemblies don't need to reference MVC in any way. That shouldn't be any different in any DI framework. MVC DI will instantiate things but the things don't need to know anything about MVC. – Sami Kuhmonen Jul 19 '16 at 14:01
  • I think you are confusing a thing here. The `Microsoft.Extensions.DependencyInjection` isn't part of ASP.NET Core / MVC, it's it's own package and can be used in console applications or class libraries (i.e. for modules to encapsulate the registrations) – Tseng Jul 19 '16 at 14:32
  • If you are using DI, then why is the `BLL` referencing the `DLL` and/or `Database`? That sounds the exact opposite of DI to me. The `DLL` should reference the `BLL`, since then, and only then, can the `DLL` implement the required contracts (interfaces) that the `BLL` defines. And then you hook it up using `DI`. – Maarten Jul 20 '16 at 07:33

1 Answers1

4

Personally I have a few things I would change about the overall structure, but I'm guessing a full design review isn't really what you're asking for. ON your actual question, no - your other layers do not need to reference MVC.

For most any application, IoC needs to be configured and initialized in the presentation layer. Ultimately your presentation layer needs a reference chain (direct or indirect references) to everything you want to register, but this has always been true.

You are already referencing Helpers, Resource, ViewModel, and BLL so you can easily register implementations for the interfaces in those layers. You could also add a reference to DLL to register implementations from that layer.

You can also go the indirect route and add a class in each layer which takes a reference to your IoC container and handles its own registration. In Autofac this is done using modules but there are equivalent ways of accomplishing the same thing using other IoC containers.

Tim Copenhaver
  • 3,282
  • 13
  • 18
  • Modules are the way to go if one wants to encapsulate the service implementations and to prevent accidental usage of `new` keywords on that implementations. One would just mark the implementations as internal, so they can't be referenced from the application project (ASP.NET Core project in this case) – Tseng Jul 19 '16 at 14:34