Develop Reference

C# Dependency Injection with 3 projects on same Solution

I have a solution with separate projects. The structure is like this:
1 - the web project
2 - the Aplicacao, that is called by the controllers of 1 to do the logic
3 - the Dominio, that has the classes of my solution
4 - the Dados, that has the entity framework stuff...
So, when I have a POST to register a new user, the UsuarioController (UC) is called. The UC has to instanciate a UsuarioAplicacao (UA) passing a usuario. The UA has to instanciate a UsuarioRepositorio (UR) passing a usuario as parameter and here it will be salved to the database.
I'm used to instanciate the class I need inside the constructor of the class, like so:
public ActionResult Registrar (Usuario usuario)
{
if (ModelState.IsValid)
{
var _usuarioApp = new UsuarioAplicacao();
_usuarioApp.Salvar(usuario);
rest of the code...
}
}
But, while studing, I've learned that this isn't quite right. I should use the dependency injection (DI)...
So, using DI with the constructor, I can't figure out how to do it...
I've tried like this in my controller:
private UsuarioAplicacao _usuarioAplicacao;
public UsuarioController (UsuarioAplicacao usuarioAplicacao)
{
this._usuarioAplicacao = usuarioAplicacao;
}
then, on my UsuarioAplicacao (class that do the logics and call UsuarioRepositorio to save the object into the DB):
private readonly UsuarioRepositorio _usuarioRepositorio;
public UsuarioAplicacao (UsuarioRepositorio usuarioRepositorio)
{
this._usuarioRepositorio = usuarioRepositorio;
}
and finnaly, inside my UsuarioRepositorio (class responsable for saving tha data into the DB via Entity Framework):
private readonly Contexto _contexto;
public UsuarioRepositorio(Contexto contexto)
{
this._contexto = contexto;
}
(_contexto is my EF context class)
These are my onstructors. But I'm getting Null Reference Exceptions...
Can you guys help me with dependency injection?
Ninject I couldn't understand how to use either...
thanks in advance

you are getting null references because you didn't configure any dependency injection. Simply passing a parameter on the controller constructor is not enough, you have to actually tell the depedency injector how to construct your dependencies.
Using Unity, you do something like this on your WebApiConfig (or global.asax if on mvc)
public static void UnityContext_OnRegisterComponents(Microsoft.Practices.Unity.UnityContainer container)
{
container.RegisterType<ICarRepository, CarRepository>(new HierarchicalLifetimeManager());
}
Now, for the concept of dependency injection, it is used to keep low coupling among projects. Your controller must not know your Business rules, neither how to create objects that belong to another assembly.
Example: When you create your repositories and isntantiate your entities directly on the controller, you are creating a dependency between those assemblies, making it really hard to test your code later, also making it a lot more complex.
In terms of architecture, I use something like this:
Web - Front end
Business - Where you do your business Rules
Contracts - Where you declare your data transfer objects
Data - Where you declare your entities, and entity framework do low level stuff, like opening connections, saving things to the database and etc, and where you declare your repositories
In that architeture:
Web access Contracts and Business
Business access Contracts and Data
Data Doesnt Access Anything
Business will ask Data for entities, Data will answer with the entity models from your database, and any manipulation you need to do, will be done in the business, returning a data transfer object (of the Contracts assembly), which will them be used in your front end, either as it is returned, or defining a new model to fit the transfer object into your front end.
In this scenario, keeping dependency injection in mind, it would create a coupling if the business layer knew how to create Data Layer objects, so instead of doing this, you configura a dependency injection container, and that object will be responsible for instantiating everything that every layer needs, keeping all your projects decoupled.

Removing Dependency From Controller Constructor in MVC

I am creating a MVC application using NINject as my IOC. I am trying to separate my business logic from controller. And so I don't want my controller constructor creates for my any Dependency Object i.e. I dont want to pass my interface in the constructor and than it gets resolved through IOC container. It should be the responsibility of the business logic layer. I am trying to achieve something like below.
public BusinessHolidayController()
{
}
// GET: BusinessHoliday
public ActionResult Index(Product product)
{
string model = invoke<IProduct>().GetSum(product);
return View(model);
}

What you are above to do is leaning toward Service Locator Pattern which is anti-pattern and a dangerous pattern. Its disadvantages are greater than its advantages.
There are four basic DI patterns -
Constructor Injection
Property Injection
Method Injecton
Ambient Context
For MVC controller, you want to use Constructor Injection, because it is the best pattern of the above four patterns especially for controller.
It should be the responsibility of the business logic layer.
No. Composite Root should be placed entry point of the application such as Global.asax.
For more information, you want to read Mark Seemann's Dependency Injection in .NET.

Design issue with interaction between Service Layer and DAL Layer

I have a design problem with my poject that I don't know how to fix, I have a DAL Layer which holds Repositories and a Service Layer which holds "Processors". The role of processors is to provide access to DAL data and perform some validation and formatting logic.
My domain objects all have a reference to at least one object from the Service Layer (to retrieve the values of their properties from the repositories). However I face two cyclical dependencies. The first "cyclical dependency" comes from my design since I want my DAL to return domain objects - I mean that it is conceptual - and the second comes from my code.
A domain object is always dependent of at least one Service Object
The domain object retrieves his properties from the repositories by calling methods on the service
The methods of the service call the DAL
However - and there is the problem - when the DAL has finished his job, he has to return domain objects. But to create these objects he has to inject the required Service Object dependencies (As these dependencies are required by domain objects).
Therefore, my DAL Repositories have dependencies on Service Object.
And this results in a very clear cyclical dependency. I am confused about how I should handle this situation. Lastly I was thinking about letting my DAL return DTOs but it doesn't seem to be compatible with the onion architecture. Because the DTOs are defined in the Infrastructure, but the Core and the Service Layer should not know about Infrastucture.
Also, I'm not excited about changing the return types of all the methods of my repositories since I have hundreds of lines of code...
I would appreciate any kind of help, thanks !
UPDATE
Here is my code to make the situation more clear :
My Object (In the Core):
public class MyComplexClass1
{
MyComplexClass1 Property1 {get; set;}
MyComplexClass2 Property2 {get; set;}
private readonly IService MyService {get; set;}
public MyComplexClass1(IService MyService)
{
this.MyService = MyService;
this.Property1 = MyService.GetMyComplexClassList1();
.....
}
This is my Service Interface (In the Core)
public interface IService
{
MyComplexClass1 GetMyComplexClassList1();
...
}
This my Repository Interface (In the Core)
public interface IRepoComplexClass1
{
MyComplexClass1 GetMyComplexClassObject()
...
}
Now the Service Layer implements IService, and the DAL Layer Implements IRepoComplexClass1.
But my point is that in my repo, I need to construct my Domain Object
This is the Infrascruture Layer
using Core;
public Repo : IRepoComplexClass1
{
MyComplexClass1 GetMyComplexClassList1()
{
//Retrieve all the stuff...
//... And now it's time to convert the DTOs to Domain Objects
//I need to write
//DomainObject.Property1 = new MyComplexClass1(ID, Service);
//So my Repository has a dependency with my service and my service has a dependency with my repository, (Because my Service Methods, make use of the Repository). Then, Ninject is completely messed up.
}
I hope it's clearer now.

First of all, typically architectural guidance like the Onion Architecture and Domain Driven Design (DDD) do not fit all cases when designing a system. In fact, using these techniques is discouraged unless the domain has significant complexity to warrant the cost. So, the domain you are modelling is complex enough that it will not fit into a more simple pattern.
IMHO, both the Onion Architecture and DDD try to achieve the same thing. Namely, the ability to have a programmable (and perhaps easily portable) domain for complex logic that is devoid of all other concerns. That is why in Onion, for example, application, infrastructure, configuration and persistence concerns are at the edges.
So, in summary, the domain is just code. It can then utilize those cool design patterns to solve the complex problems at hand without worrying about anything else.
I really like the Onion articles because the picture of concentric barriers is different to the idea of a layered architecture.
In a layered architecture, it is easy to think vertically, up and down, through the layers. For example, you have a service on top which speaks the outside world (through DTOs or ViewModels), then the service calls the business logic, finally, the business logic calls down to some persistence layer to keep the state of the system.
However, the Onion Architecture describes a different way to think about it. You may still have a service at the top, but this is an application service. For example, a Controller in ASP.NET MVC knows about HTTP, application configuration settings and security sessions. But the job of the controller isn't just to defer work to lower (smarter) layers. The job is to as quickly as possible map from the application side to the domain side. So simply speaking, the Controller calls into the domain asking for a piece of complex logic to be executed, gets the result back, and then persists. The Controller is the glue that is holding things together (not the domain).
So, the domain is the centre of the business domain. And nothing else.
This is why some complain about ORM tools that need attributes on the domain entities. We want our domain completely clean of all concerns other than the problem at hand. So, plain old objects.
So, the domain does not speak directly to application services or repositories. In fact, nothing that the domain calls speaks to these things. The domain is the core, and therefore, the end of the execution stack.
So, for a very simple code example (adapted from the OP):
Repository:
// it is only infrastructure if it doesn't know about specific types directly
public Repository<T>
{
public T Find(int id)
{
// resolve the entity
return default(T);
}
}
Domain Entity:
public class MyComplexClass1
{
MyComplexClass1 Property1 {get; } // requred because cannot be set from outside
MyComplexClass2 Property2 {get; set;}
private readonly IService MyService {get; set;}
// no dependency injection frameworks!
public MyComplexClass1(MyComplexClass1 property1)
{
// actually using the constructor to define the required properties
// MyComplexClass1 is required and MyComplexClass2 is optional
this.Property1 = property1;
.....
}
public ComplexCalculationResult CrazyComplexCalculation(MyComplexClass3 complexity)
{
var theAnswer = 42;
return new ComplexCalculationResult(theAnswer);
}
}
Controller (Application Service):
public class TheController : Controller
{
private readonly IRepository<MyComplexClass1> complexClassRepository;
private readonly IRepository<ComplexResult> complexResultRepository;
// this can use IoC if needed, no probs
public TheController(IRepository<MyComplexClass1> complexClassRepository, IRepository<ComplexResult> complexResultRepository)
{
this.complexClassRepository = complexClassRepository;
this.complexResultRepository = complexResultRepository;
}
// I know about HTTP
public void Post(int id, int value)
{
var entity = this.complexClassRepository.Find(id);
var complex3 = new MyComplexClass3(value);
var result = entity.CrazyComplexCalculation(complex3);
this.complexResultRepository.Save(result);
}
}
Now, very quickly you will be thinking, "Woah, that Controller is doing too much". For example, how about if we need 50 values to construct MyComplexClass3. This is where the Onion Architecture is brilliant. There is a design pattern for that called Factory or Builder and without the constraints of application concerns or persistence concerns, you can implement it easily. So, you refactor into the domain these patterns (and they become your domain services).
In summary, nothing the domain calls knows about application or persistence concerns. It is the end, the core of the system.
Hope this makes sense, I wrote a little bit more than I intended. :)

Why Interface Layer/Abstract classes required in our project? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We normally use abstract function/Interfaces in our projects. Why it is really needed? Why can't we just go for Business logic Layer, Data Access Layer and Presentation Layer only
Function in Presentation Layer:
abc();
Function in Business Logic Layer:
public void abc()
{
//Preparing the list
}
Function in Data Access Layer:
public abstract void abc();
Function in Data Access SQLServer Layer:
public override void abc()
{
//Connection with database
}
Question is: Why is the Data Access Layer required ?

The easiest way to understand this, imo, is an abstraction over DataLayer.
You have set a functions to retrieve a data from xml file. But one day your product scales out and xml is not enough like a data storage. So you pass to some embeded database: sqlite. But one day you need to reuse your library in some enterprise context. So now you need to develop access to sqlserver, oracle, webservice.... In all these changes you will need to change not only the code that actually access the data, but the code that actually consumes it too. And what about the code that already use for years your first xml data access on client and happy with it? How about backcompatibility?
Having the abstraction if not direcly solves most of this problems, but definitely makes scallable your application and more resistant to changes, that, in our world, happen sometimes too frequently.

Generally, if you use interfaces in your code, then you will gain code manuverability in the form of Dependency Injection.
This will help you replace parts of your implementation in certain situations for example providing Mock objects during Unit Testing.

The abstract class or interface is not really a separate layer - it should be part of your business logic layer and it defines the interface that the actual data access layer (SQL data repository, for example) needs to implement to provide the data access service to your business layer.
Without this interface your business layer would be directly dependent on the SQL layer, while the interface removes this dependency: You put the abstract class or the interface into the business logic layer. Then the SQL layer (a separate assembly, for example) implements the abstract class/interface. This way the SQL layer is dependent on the business layer, not the other way around.
The result is a flexible app with an independent business layer that can work with multiple data repositories - all it needs is a layer that implements the interface the business layer defines. And it is not really only about data repositories - your business layer shouldn't be dependent on the context (asp.net vs. console app vs. service etc.), it shouldn't be dependent on the user interface classes, modules interfacing with your business app, etc.

Why interfaces :
Have you ever used using in c# :
using (Form f = new Form())
{
}
Here you will see that you can use only those classes inside using which implements IDisposable interface .
Two things which does not know each other can interact with each other using Interfaces only.
Interface gurantees that "some" functionality has surely been implemented by this type.
Why layers :
So that you can have separate dlls which will let you to reuse in different application.
Basically all is for code reuse and Performance gain.

I think you are talking about Facade layer.
It is an optional layer which will simplify the functions of Business Layer. Let's imagine, you have a ProductManager and CategoryManager and you want to do a particular action which involves using both (for example, get me top 5 products in all categories) then you could use a facade layer that uses ProductManager and CategoryManager.
It is inspired by Facade Pattern.

The abstraction helps create functionality, be it through a base class, an interface, or composition which, when used properly, does wonders for maintenance, readability, and reusability of code.
In regards to the code posted in the question, the code marked "Data Access Layer" acts as a common abstraction for the business layer to use. By doing so, the specific implementations of the the DAL (such as what's under "Data Access SQLServer Layer" in the sample) are decoupled from the business layer. Now you can make implementations of the DAL that access different databases, or perhaps automatically feed data for testing, etc.
The repository pattern is a fantastic example of this at work in a DAL (example is simplified):
public interface IProductRepository
{
Product Get(int id);
...
}
public class SqlProductRepository : IProductRepository
{
public Product Get(int id) { ... }
...
}
public class MockProductRepository : IProductRepository
{
private IDictionary<int, Product> _products = new Dictionary<int, Product>()
{
{ 1, new Product() { Name = "MyItem" } }
};
public Product Get(int id) { return _products[id]; }
...
}
public class AwesomeBusinessLogic
{
private IProductRepository _repository;
public AwesomeBusinessLogic(IProductRepository repository)
{
_repository = repository;
}
public Product GetOneProduct()
{
return _repository.GetProduct(1);
}
}
Even though this example uses interfaces, the same applies to the use of base classes. The beauty is that now I can feed either SqlProductRepository or MockProductRepository into AwesomeBusinessLogic and not have to change anything about AwesomeBusinessLogic. If another case comes along, all that's needed is a new implementation of IProductRepository and AwesomeBusinessLogic will still handle it without change because it only accesses the repository through the interface.

All of the previous answers may explain the needs of abstract layers, but I still want to add some of my thoughts.
Let's say that in our project we just have one implementation of a service in each layer. For instance, I have a contact DAL and a contact BLL service , and we could do something like this
namespace Stackoverflow
{
public class ContactDbService
{
public Contact GetContactByID(Guid contactID)
{
//Fetch a contact from DB
}
}
}
Contact BLL service:
namespace Stackoverflow
{
public class ContactBLLService
{
private ContactDbService _dbService;
public ContactBLLService()
{
_dbService = new ContactDbService();
}
public bool CheckValidContact(Guid contactID)
{
var contact = _dbService.GetContactByID(contactID);
return contact.Age > 50;
}
}
}
without defining interfaces/ abstract classes.
If we do like that, there would be some obvious drawbacks.
Code communication:
Imagine that if your project involves, your services may have many different methods, how could a maintainer (apart from you) know what your services do? Will he have to read your entire service in order to fix a small bug like InvalidCastOperation?
By looking at the interface, people will have the immediate knowledge of the capabilities of the service(at least).
Unit testing
You could test your logic using a fake/mock service to detect bugs in advance as well as prevent regression bugs from happening later.
Easier to change:
By referencing only by interfaces/ abstract classes in other classes, you could easily replace those interface implementations later without too many efforts of work.

Abstraction enables you to do refactoring quickly. Think of instead of using SQL server, you decide to use some other provider; if you do not have a data access layer, then you to do a huge refactor because you are calling data access methods directly. But if you have a data access layer, you only write a new data access layer, inheriting from your abstract data access layer and you do not change anything in the business layer.

Does a service layer act as a facade for the DAL?

I am reading up about service layers and repositories. Now I am wondering if a service layer must wrap the dal. I am working a lot with repositories and the MVP pattern. The presenters now holds the business logic. But the more I think about it, it is not a logic place to put the business logic in the presenter nor the data access layer. So this is the point the service layer comes in.
But does the presenter now talks to the service layer? And is it 'allowed' that the presenter can access the repositories? Or should everything go via the service layer? In the latter case, the service layer is just a middleman:
MyFooService:
public List<Foo> GetAllFoo()
{
var listFoo = new FooRepository().GetAll().TiList();
return listFoo;
}
Presenter:
public List<Foo> GetAllFoo()
{
var listFoo = new MyFooService().GetAllFoo();
return listFoo;
}
Is the good way to go? Or is it 'allowed' that the presenter directly calls the repository?

Sometimes you do not need to over engineer things or force into patterns when you don't need them.
The DAL, is itself sorta a special service to access data.
Typically your service layer will do stuff not related directly to your data. Think things like PaymentService, AnalyticsService etc things like that, that can be separated into a re-usable component.
Lets say you needed to share a post on to all social media, you could put this into a service that does the job of signing into the right social media and posting:
MySocialBlastService : ISocialService
{
void ShareToTwitter() { }
void ShareToFacebook(){ }
}
Now from your controller/presenter you can call this service.
public ActionResult ShareLink(string link..) //asp.net-mvc method as an example
{// maybe you could use dependency injection here to get ISocialService
ISocialService _service;
_service.ShareToTwitter(link);
}
Just so you're clear on what business logic is:
MathService
{
int Add(a,b) { ..} //this is business logic
}
Its some stuff you need to do, and you can do it without touching an interface, this needs to be encapsulated. More real world examples are SecurityService.ResetPassword()
When you call this from the controller:
You could use the business logic of adding in a web app, or in a windows app, and get the inputs from the user through some interface. How you do that is controller logic.
public ActionResult Calculate(int a, int b)//comes from webpage
{
//this is controller logic
int ret = MathService.Add(a,b);
//logic to send ret back
//to some other page to display to user.
}

I would say that if you are doing "serious" middle to big scale development it is better not to put business logic into your presentation layer. How you isolate it is another question.
On the other side if you use something like Entity Framework or NHibernate I would only create repositories if it is really necessary to abstract data access, for using mocks when testing, for example.