N层架构与服务层，业务层，和Entity Framework [英] N-Tier Architecture with Service Layer, Business Layer, and Entity Framework

问题描述

只是想和我architecturing我的应用程序的方式一些反馈/帮助。我目前的解决方案的结构看起来是这样的：

Just wanted some feedback/help with the way I'm architecturing my application. My current solution structure looks something like this:

• UI（实际MVC应用程序）


• 核心（仅控制器和放大器;的ViewModels）


• 服务


• BLL


• 数据（实体框架的DbContext，映射到域对象）


• 域（简单对象POCO）


• 接口

其他的东西。

• Ninject注入的DbContext到控制器（每个请求）


• AutoMapper映射域对象到视图模型

所有的组件都在界面项目，该项目，顾名思义，无非是简单的界面（即IDbContext，IRepository等）更多的引用

All assemblies have a reference to the Interfaces project, which, as the name suggests, is nothing more than simple interfaces (i.e. IDbContext, IRepository, etc).

服务项目联系起来一切。它是一种具有直接引用数据访问层（实体框架）。唯一的组装

The Services project "ties" together everything else. It is the only assembly which has a direct reference to the Data access layer (Entity Framework).

我提供了下面的一些code：

I've provided some code below:

一个控制器的一个例子是这样的：

An example of a Controller looks like this:

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));
        }
        ...

将UserService类：

The UserService class:

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();
        }
        ...

最后，业务层类：

Finally, the business layer class:

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();
        }
        ...

我在寻找一些反馈/改进的方法。我注意到，对于基本任务，我的服务层的方法将是完全一样的业务层的方法（即通过功能）。什么我希望的是，这种抽象会更复杂的任务可能需要多个业务层方法的调用很有帮助。这纯粹是更好的，包括在服务层的业务逻辑？

I'm looking for some feedback/ways to improve. I notice that for basic tasks, my service layer methods will be exactly the same as the business layer methods (i.e. "pass through" functions). What I'm hoping is that this abstraction will be helpful for more complex tasks which may require calls to multiple business layer methods. Would it just be better to include business logic in the service layer?

推荐答案

从看一眼，我不认为你的服务和控制器/核心层应具有注入他们以这种方式分贝范围内。他们实际上并不直接依赖于它，并以这种方式做会导致一些耦合是不理想。核心层应具有注入的用户业务和用户的服务和BLL应具有库注入。存储库应具备的DbContext你DI框架注射没有传过来的依赖关系。

From a quick glance, I don't think your service and controller/core layer should have the db context injected into them in this manner. They don't actually directly depend on it and doing it in this manner causes some coupling that is not ideal. The core layer should have the user service injected and the user service and BLL should have the repository injected. The repository should have the dbcontext injected by your DI framework and not passed in as a dependency.

这篇关于N层架构与服务层，业务层，和Entity Framework的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！