5

只是想对我构建应用程序的方式提供一些反馈/帮助。我当前的解决方案结构如下所示：

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

其他的东西

  • Ninject 将 DbContext 注入控制器（每个请求）
  • AutoMapper 将域对象映射到 ViewModel

所有程序集都有一个对 Interfaces 项目的引用，顾名思义，它只不过是简单的接口（即 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));
        }
        ...

用户服务类：

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

我正在寻找一些反馈/改进方法。我注意到对于基本任务，我的服务层方法将与业务层方法完全相同（即“通过”功能）。我希望这种抽象有助于更复杂的任务，这些任务可能需要调用多个业务层方法。在服务层中包含业务逻辑会更好吗？

4

4 回答 4

9

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

于 2012-08-22T20:14:17.020 回答
4

为什么直接在服务中创建依赖项时使用依赖项注入？

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

顺便提一句。当它们实际上什么都不做时，你为什么要使用这么多层？您的示例代码只是表明，直接在控制器中使用上下文会产生相同的结果，而无需三个包装无用的层。这可能只是您的示例的问题，但每一层都应该带来一些额外的逻辑。如果您只是使用它来调用较低层的某些东西，那么您很可能会过度构建您的代码。这称为洋葱架构。这也是为什么在需要时添加图层并不是一个坏习惯的原因 - 而不是预先添加图层。

于 2012-08-22T20:12:18.577 回答
1

请查看： http: //www.primaryobjects.com/CMS/Article122.aspx EF 存储库模式 + 工作单元模式。至于您的其他层，它实际上取决于应用程序及其需要完成的任务。请提供有关您要执行的操作的更多详细信息。

于 2012-08-22T20:18:25.173 回答
0

在组织项目和层设计方面的一些改进可以通过专注于使域对象正确来完成。

您说您有简单的 POCO 对象作为域，但域对象应该是具有业务的所有“状态和行为”的对象。这意味着您不需要将 BLL 和域程序集分开。定义域对象后，可以使用 EF 创建上下文和实体类（它们不是域类，除非与域对象相比没有其他行为，但它们仍然不同可能有利于未来的需求）。

另一个小问题是，我认为将接口分布在域和服务层中对于任何人都孤立地理解每一层来说更好。

于 2016-02-28T06:55:26.733 回答