N-Tier-Architektur mit Service Layer, Business Layer und Entity Framework
Ich wollte nur ein Feedback / Hilfe bei der Architektur meiner Anwendung. Meine aktuelle Lösungsstruktur sieht ungefähr so aus:
Benutzeroberfläche (aktuelle MVC-Anwendung)Core (nur Controller und ViewModels)DienstleistungenBLLDaten (Entitätsframework DbContext, Domänenobjekten zugeordnet)Domäne (einfache POCO-Objekte)SchnittstellenAndere Sachen
Ninject, um DbContext in den Controller einzufügen (auf Anfrage)AutoMapper zum Zuordnen von Domänenobjekten zu ViewModelAlle Assemblys haben einen Verweis auf das Interfaces-Projekt, das, wie der Name schon sagt, nichts anderes als einfache Interfaces ist (d. H. IDbContext, IRepository usw.).
Das Services-Projekt "bindet" alles andere zusammen. Es ist die einzige Assembly, die einen direkten Verweis auf die Datenzugriffsebene (Entity Framework) hat.
Ich habe unten einen Code angegeben:
Ein Beispiel für einen Controller sieht folgendermaßen aus:
namespace Core.Controllers
{
public class HomeController : Controller
{
private IDbContext dbContext;
public HomeController(IDbContext dbContext)
{
this.dbContext = dbContext;
}
public ActionResult Users()
{
UserService userService = new UserService(dbContext);
var users = userService.GetAllUsers();
return View(Mapper.Map<IEnumerable<UserListViewModel>>(users));
}
...
Die UserService-Klasse:
namespace Services
{
public class UserService
{
private readonly IDbContext dbContext;
public UserService(IDbContext dbContext)
{
this.dbContext = dbContext;
}
public IEnumerable<User> GetAllUsers()
{
IRepository<User> userRepository = new Repository<User>(dbContext);
UserBLL userBLL = new UserBLL(userRepository);
return userBLL.GetAllUsers();
}
...
Schließlich die Business-Layer-Klasse:
namespace BLL
{
public class UserBLL
{
private readonly IRepository<User> userRepository;
public UserBLL(IRepository<User> userRepository)
{
this.userRepository = userRepository;
}
public IEnumerable<User> GetAllUsers()
{
return userRepository.Get();
}
...
Ich suche nach Feedback / Verbesserungsmöglichkeiten. Ich stelle fest, dass meine Service-Layer-Methoden für grundlegende Aufgaben genau den Business-Layer-Methoden entsprechen (d. H. Durchleitungsfunktionen). Ich hoffe, dass diese Abstraktion für komplexere Aufgaben hilfreich sein wird, für die möglicherweise mehrere Business-Layer-Methoden aufgerufen werden müssen. Wäre es einfach besser, Geschäftslogik in die Serviceschicht aufzunehmen?