Last post Jul 13, 2014 12:34 PM by jammycakes
Jun 20, 2014 01:07 AM|zielony|LINK
I have Web project which has got reference do BLL project. BLL project has got reference to DAL project. To dependency injection I use ninject in Web project.
In DAL project I have for example class:
public class UnitOfWork : IUnitOfWork
which is used in BLL project.
I can't make in Web project that injection:
Because Web project doesn't know anything about DAL project. What can I do?
Jun 20, 2014 02:54 AM|me_ritz|LINK
Exactly what you should do to set up dependencies to avoid the problem...http://stackoverflow.com/questions/22276523/dependency-injection-in-a-3-layer-asp-net-mvc-application
Jun 20, 2014 03:22 AM|zielony|LINK
In their solution I have to add reference to DAL project from UI project - is it ok?
Jun 20, 2014 04:34 AM|me_ritz|LINK
Jun 20, 2014 01:54 PM|Yorrick vd Voort|LINK
With all due respect… It is never OK to access the DAL from the UI layer. If you ever feel the need to access the DAL from the UI layer than don’t create an n-tier architecture. Just create a simple “one project” solution that contains all tier logic. Which
is fine BTW, if loosely coupled and changeability is not a factor in your application, think about small applications, just go ahead. But when working on a product like application that will undergo a lot of changes over time, don’t even try to go there. Separation
of Concerns (SoC) is your friend in “big product” like applications.
The Unit of Work (UoW) shouldn’t reside in the UI layer at all. The UI layer is all about telling “What” to do, not telling “How” to do it. Implementing a “UoW” in a UI layer is telling “How” not “What” The “How” is what the BLL is all about. The DAL in
its turn will have knowledge on “How” to handle data requests.
Hope this helps.
Jun 21, 2014 03:03 PM|me_ritz|LINK
Yorrick vd Voort
With all due respect… It is never OK to access the DAL from the UI layer.
well...it is not accessing DAL from UI Layer....it needs it to inject dependency...
Yorrick vd Voort
If you ever feel the need to access the DAL from the UI layer than don’t create an n-tier architecture. Just create a simple “one project” solution that contains all tier logic.
the OP never asked to access DAL from UI Layer...he just wanted to cofirm if it is ok to add reference to DAL from UI ( given what is the current dependency of his application, if he can't choose flatter dependency then it's OK...see the link in previous
Jun 24, 2014 08:00 AM|Yorrick vd Voort|LINK
I must have misunderstood the question. But I still think it is not OK to reference the DAL dll in your UI layer. Even if it is just for the fact that fellow programmers on your
project don’t get tempted to bypass the BLL layer all together, if you give an opportunity there is bound to be someone to take advantage of it. Keep it separated; the UI layer shouldn’t have any knowledge of other layers what so ever.
Instead of binding your Interfaces to concrete implementations in the global.asax on application start, use configuration files instead. That way you don’t have to have references
to all projects in your solution and you can change implementations without having to rebuild the app. Just remember to copy the dlls to the bin folder of the UI app, you can use the post build events in the property settings of your project file. See this
link for more details: http://stackoverflow.com/a/11001949
Now I don’t have experience with Ninject but the following link shows how to do that:
Although some might say that it isn’t type save and mistakes are made easily, I still favor this approach over the other. You should test your application anyways, especially
the parts you made changes on, so typos in this config file will come out sooner or later.
Jul 13, 2014 12:34 PM|jammycakes|LINK
Yorrick vd Voort
I must have misunderstood the question. But still think it is not OK to reference the DAL dll in your UI layer. Even if it is just for the fact that fellow programmers on your project don’t get tempted to bypass the BLL layer all together, if you give an opportunity
there is bound to be someone to take advantage of it. Keep it separated; the UI layer shouldn’t have any knowledge of other layers what so ever.
While this limitation is all very well in theory, in practice it frequently results in an antipattern that I call the Anaemic Business Layer. This is where you have business "logic" classes that do not contain any logic whatsoever, but just shunt data between
one set of classes returned from your DAL and another set of identical classes with identical signatures in a different namespace. This is bad because it forces you to jump through more source files to see what's going on and increases the number of files
that you have to edit in order to make a change, thereby increasing risk. If you're implementing an Anaemic Business Layer, you may be putting business logic in your repository, which adversely affects testability, but if you aren't, then I would argue that
you should have the option in this case to bypass your business layer and go directly from your UI to your DAL.
I also don't like the habit of putting separate layers in different assemblies. Assemblies are a unit of
deployment, not a unit of organisation, and putting your different layers in different assemblies is a violation of the
Common Closure Principle, which says that classes that change together should be packaged together. The general rule is that you should keep the number of assemblies in your solution to
a minimum, otherwise you're going to make dependency management harder (upgrading NuGet packages etc) and slow down compile times. See
this blog post by Jeremy Miller for a more in-depth discussion.
Yorrick vd Voort
Instead of binding your Interfaces to concrete implementations in the global.asax on application start, use configuration files instead.
I'd suggest trying
convention-based binding for Ninject instead. You can specify assemblies by name as well as by reference, so you wouldn't need to reference all your assemblies from your UI. XML configuration files are best kept to a minimum because they can be difficult