N层架构与服务层，业务层，和Entity Framework(N-Tier Architecture

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

UI（实际MVC应用程序）
核心（仅控制器和的ViewModels）
服务
BLL
数据（实体框架的DbContext，映射到域对象）
域（简单对象POCO）
接口

其他的东西

Ninject注入的DbContext到控制器（每个请求）
AutoMapper映射域对象到视图模型

所有组件都在接口项目，其中，顾名思义，无非是简单的接口（即IDbContext，IRepository等）更多的参考。

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

我在下面提供了一些代码：

控制器的例子是这样的：

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类：

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

最后，业务层类：

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

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

Answer 1:

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

Answer 2:

你为什么要使用依赖注入，当你在服务直接创建依赖？

public IEnumerable<User> GetAllUsers()
{
    IRepository<User> userRepository = new Repository<User>(dbContext);
    UserBLL userBLL = new UserBLL(userRepository);
    return userBLL.GetAllUsers();
}

顺便说一句。你为什么要使用这么多层次的时候，他们实际上什么也不做？您的示例代码只是表明在控制器直接使用上下文会产生无三个包装无用层相同的结果。这可能是你的榜样仅仅问题，但每一层应该带来一些额外的逻辑。如果你只是用它来打电话给你是最有可能overarchitecting代码下层的东西。这就是所谓的洋葱架构。这也是一个原因，它不是一个坏习惯，一旦你需要它添加图层 - 没有前期。