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
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?
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.
Related
I recently have read about the domain driven design. Finally, I came across the structure that my project should have. The structure would be like :
MyApp.Domain which contains entities and repositories interfaces.
MyApp.Domain.Services contains services.
MyApp.Infrastructure
MyApp.Persistence Contains the repositories implementation
MyApp.Application contains viewmodels and services
MyApp.Site
Right now, I just need to reference the MyApp.Domain and MyApp.Application to my site. On the other hand, if I want to use Unity as Ioc. The question is, Should I make reference to MyApp.Domain.Services and MyApp.Persistence as well? in order to register types?
Thanks
How else would Your "Application" know about Your business objects,
if You don't tell it, which assembly they're registered in ?
If You're looking for a more 'Plug-in' based approach, then it's a different story..
If speaking about plugins (not sure how Unity does that)
but the only way I got this to work (withing reasonable amount of effort)
was unit Autofac modules
You'd still need to have a place where You register your assemblies
and have something like a 'Filesystem watcher' that monitors a pat for new .dll's and loads them ect..
A common architecture when practicing DDD is the Onion Architecture. Mostly because it has several improvements over a typical n-tier architecture with barely any downsides.
It allows your domain and domain model to be at the heart of the software. The domain services layer would usually have a dependency on the persistence layer. In an Onion Architecture, this is flipped and the persistence layer holds the references to the domain services/model. To access the persistence layer, the interfaces for the key classes in the persistence layer are held in the domain layer and IoC is used to wire up the instantiation.
First of all, why have you created six different projects? They are just a fictionary separation. If you are the only developer, do you not trust yourself? If you are more than one developer, are your communication so bad that you can't agree on in which direction dependencies go?
Good separation comes from communication and talk within a team, and not because you have created multiple projects (adding a reference is really easy).
If you want to make sure that the code keeps good quality, introduce code reviews, measure the quality with the built in analytic tools or simply write unit tests.
Therefore, project references are not the problem and never have been. Add the reference in a way that makes it easy to run and maintain the application.
If you are serious about DDD forget about the project structure. It doesn't really matter that much. Understand the methodology and what's important in DDD. Buy the blue book by Eric Evans.
I am pretty new to MVC and I am currently working on an MVC 3 project in visual studio and I want to create a method or variable that is accessible globally. When I say globally I mean available in my web project, service layer project, and data layer project.
I guess when I say global I mean global to the entire solution.
I tried creating a class in the solution items folder and referencing in my web project but its not letting me add a reference to the class since it is not a DLL.
I am a little confused with how to do this. Any suggestion would be appreciated. Also keep in mind that though I am a programmer I am still somewhat new to MVC and programming.
Edit: I have also tried adding a method in the global.asax file but was unable to call it
You should create a shared assembly where you define the class. You can then add a reference to the shared assembly from all projects that need the feature.
The class that you want to be "global" sounds like some sort of service. I suppose this is the kind of thing you may want to do with a logging service for example.
Using a logging service as an example it is generally best practice for the interface to the logging service be defined in a lightweight contracts type assembly. Then any of your assemblies that require an implementation of ILoggingService should inject the necessary implementation using an IoC container such as Autofac or MEF.
This pattern is pretty common and allows you to share common services while keeping implementations loosely coupled. Also this pattern will lead to highly testable code as fake implementations can be injected with Moq
I'm trying to use Simple Injector in a project which has the following architecture :
DAL layer(owns a repositories),
BLL layer(owns a services that talks to the repositories),
MVC layer(talks to the services in the BLL layer).
when it comes to register with the container the classes and the interfaces, I`m facing a problem, Simple Injector needs me to register the repository with its interface (as my classes in the service layer accepts a repository in their constructor)
So, actually, Simple Injector forces me to add a references to my DAL layer in my MVC layer which i really like to avoid.
My question is, is it possible/right to make an external project that will hold only Simple Injector, and this project will have reference to all other projects and that way i would be able to register what i want and still keep my project abstraction?
or there is any other easy way to solve this ?
A DI Container (e.g. your Simple Injector) should only be referenced from the Composition Root. All other modules should have no reference to the container.
You can read more about the Composition Root here:
http://blog.ploeh.dk/2011/07/28/CompositionRoot/
What is more DI Container should be applied using the Register Resolve Release pattern entirely from within the Composition Root.
More about this pattern here:
http://blog.ploeh.dk/2010/09/29/TheRegisterResolveReleasepattern/
I am trying to wrap my head around IoC containers. As I delve deeper into this design pattern I come across multitudes of abstraction layers, interfaces and concrete classes when before I was simply instantiating a data-context class, using it and then disposing of it.
Whilst I am keen to continue forward there are some outstanding issues I don't know how to resolve and would like some clarification and guidance.
In a generic web application with 2 projects (mvc web & data layer
containing e.f.), if our dependancy resolver expects a repository
that implements a specific interface (allowing us to switch
repositories at any time in the future), where is this interface
defined? I dont see how it can be defined in the mvc web project because then the data access layer will become dependant on it and it cannot reside in the data access layer as then the mvc project depends on the dal and i've missed the whole point of this excercise. So is
the answer to define it in both projects and have each project
reference its own copy? ..Is that even possible? Or do i need to
create a third service layer project and stick one interface
declaration in it and have both projects reference this?
Ive seen a number of articles talking about Unity IoC with
interfaces such as IProductRepository, IClientRepository and
IProductService, IClientService (this is what I was referring to in
my opening paragraph). Am I correct in assuming that each of these
instances is supposed to reference a table in my database? If so
what happens if i have 50 tables? do i need to create 50 repository
interfaces and 50 table related interfaces just to decouple everything?
And how does using EF with POCO classes impact things? do i need to
have each POCO implement its own specified interface?
thanks
Ideally you would split your solution into several projects.
You would have a contracts project where your interfaces are defined, a dal where a concrete version of those interfaces are implemented.
Your mvc project would then reference the contracts project to handle the references to the types.
You would use an IOC container to scan the assemblies in the bin folder and find a concrete implementation of the dependencies for your controller. This means that you would build your dal into the bin folder of your mvc project. This means you can switch the dal out for other implementations simply by placing a new dll in the bin folder.
As for the repositories and tables, I tend to group them by business function. So a business function of managing users and their related tables would be in a user repository etc. but that is down to personal preference imo.
When you are breaking your project into tiers you are correct in not wanting your data layer to rely on a project further up the stack. In general you want these dependencies to be unidirectional. You can either continue what you are doing and put the interfaces in the data layer, or you can create a new project to house the model code, including the repository and service interfaces. Your data layer would depend on the model code, and your mvc layer will depend on the data layer.
To address your second question I would say this is where the art of design comes in. You don't necessarily want a one to one mapping between your entities and your data tables. If it makes sense and you believe it's manageable, especially with the help of Entity Framework, then go ahead with the one to one mapping. But keep in mind that the responsibilities of the persistence layer and the domain model layer are different. If the persistence layer starts to bog down your work creating the domain model then it's time to put some work into separating the two.
More important are the interface 'facades' that are going to be exposed to the mvc project. These are going to require some degree of decoupling from the model and persistence layers. They should be distilled down to the core responsibilities of the model. You don't want to clutter your application layer with the intricacies of your domain model.
Im currently working on a project which is based on Onion Architecture . The above image Shows the Solution.
In the Infrastructure We have External Service . But the WebAPI has access only to Core .
But in the Web API project i want to access the some of the models exposed by the external services ?
How can we achieve this without adding reference to Infrastructure in the Web API .
Or we implemented Onion Architecture wrong?
conceptually you are on the right track, but the implementation isn't a hard a fast rule. to start you don't need 5+ projects at most you need 3 (web ui css/js/views, logic/controllers, code, and tests). and really you probably only need 2 (the application, the tests)
the idea of layers is conceptual, not physical. And there is not a hard and fast rule that says the layers must be completely segregated. rather the core focus of the application is what the application does. as you get into the details of how that is implemented you move to the outer layers.
in this instance you need to access data retrieved from an external service. create an abstraction for the external service IExternalServiceAdaptor. The interface may reside in the domain or server layer, but the implementation might reside in an infrastructure or outer layer where the details of how to call the external service are encapsulated within an implementation of IExternalServiceAdaptor.
If you stick with your physical separation you would have an interface in Core and the implementation in Infrstructure.
But in the Web API project i want to access the some of the models exposed by the external services ?
Actually, your WebApi project should only manipulate object defined in your Core project.
As Jason said, calls to any external services should be encapsulated within an implementation of an interface that resides in Core. And this is where models exposed by your external services will be mapped to your Core models.
Have a look at Matt Hidinger's source code on CodePlex here: http://onionarch.codeplex.com/ and check how he deals with this kind of problem, it's pretty straightforward and easy to understand.