具有服务层,业务层和实体框架的N层体系结构

Question

只是希望得到一些反馈/帮助,我正在构建我的应用程序.我目前的解决方案结构如下所示:

• UI(实际MVC应用程序)
• 核心(仅限控制器和ViewModels)
• 服务
• BLL
• 数据(实体框架DbContext,映射到Domain对象)
• 域(简单POCO对象)
• 接口

其他的东西

• Ninject将DbContext注入Controller(每个请求)
• AutoMapper将域对象映射到ViewModel

所有程序集都引用了Interfaces项目,顾名思义,它只不过是简单的接口(即IDbContext,IRepository等).

服务项目将所有其他事物"联系在一起".它是唯一一个直接引用数据访问层(实体框架)的程序集.

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

Controller的示例如下所示:

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

从快速浏览一下,我不认为您的服务和控制器/核心层应该以这种方式将db上下文注入其中.它们实际上并不直接依赖它,并且以这种方式进行它会导致一些不理想的耦合.核心层应该注入用户服务,用户服务和BLL应该注入存储库.存储库应该具有由DI框架注入的dbcontext,而不是作为依赖项传入.