Reputation: 2937
I'm building an N-Tier aplication using WCF, Entity Framework and POCO's classes for server layers, and for client i'm using WPF with the MVVM pattern. The server side code I divide it into 4 projects:
* Data Layer(DAL -> EF)
* Model Layer (POCO's classes)
* Business Layer (BAL)
* Service Layer (WCF)
For comunication between all the server layer and with the wcf client i define on Model an Interface, that i implement on every layer. I will write myself all the code, from DAL to presentation layer, so separation of concern is desirable but not essential.
So my questions:
1) Is this design make sense beeing myself the writer of all the code?
2) Should I reduce the number of proyects for the sake of simplicity?
3) Is having an interface implemented on each layer a good idea here? Because i find myself having to write very similar code 3 times for every new method. Something like this:
On WCF Service:
public IEnumerable<Clientes> GetClients()
{
BusinessLayer.Ohmio _cli = new BusinessLayer.Ohmio();
return _cli.GetClients();
}
On Business:
public IEnumerable<Clientes> GetClients()
{
DataLayer.Ohmio bn = new DataLayer.Ohmio();
return bn.GetClients();
}
On Data:
public IEnumerable<Clientes> GetClients()
{
using (var context = new OhmioEntities())
{
var _clients= context.Clientes.ToList();
return _clients;
}
}
Is see two more problems with the Interface approach:
1) I use then same Interface for comunícate server side layers and wcf client so datatype need to be the same.
2) In the case of a complex application (like the one i'm build) the interface and all the implemented classes will be huge! Because they need all the methods for all the object in my Project!
Is there a better solution for this type of cases? Any advice will be appreciated!!!! thanks!
Upvotes: 0
Views: 395
Reputation: 337
Interfaces and abstraction build the basis for dependency injection (inversion of control) allowing to test components and layers independently. Having separate layers like you suggested aids for separation of concerns reducing complexity and improving testability, maintainability, etc.
This effort might not be worth it for small and simple applications. However, the bigger and complex applications get, the more important it is to take best practices and design principles and patterns into account.
In order to avoid the effort of setting up the solution with all layers and writing all boiler plating code you might well be interested in trying out the N-Tier Entity Framework which is an open source framework perfectly matching the scenario you’ve described. In any case you should have a look at its documentation which contains a dedicated part on architectural considerations that help you in designing such a solution.
Upvotes: 1