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)Schnittstellen

Andere Sachen

Ninject, um DbContext in den Controller einzufügen (auf Anfrage)AutoMapper zum Zuordnen von Domänenobjekten zu ViewModel

Alle 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?

Antworten auf die Frage(4)

Ihre Antwort auf die Frage