c# - MVC 分层项目结构

Question

我们正在启动一个新的 Web 项目，该项目使用 C#/MVC 4 和 Entity Framework 5 进行数据访问。我已决定采用 n 层方法来构建项目结构，并且我希望获得有关我的设计决策的一些反馈。

解决方案的结构如下:

Project.Model(类库):包含 EF .edmx、实体模型和 View 模型

Project.DAL(类库):包含 EF DbContext 和 Repository 类

Project.BLL(类库):包含业务逻辑类

项目(MVC项目)

DAL

数据访问层只关心简单的 CRUD 之类的操作。我决定采用存储库方法。以下是存储库接口(interface):

public interface IRepository
{
}

public interface IRepository<T> : IRepository, IDisposable 
    where T : class, new()
{
    T Add(T item);

    T Get(object id);

    T Get(Expression<Func<T, bool>> predicate);

    IQueryable<T> GetAll();

    IQueryable<T> GetAll(Expression<Func<T, bool>> predicate);

    void Update(T item);

    void Delete(T item);
}

在对在 Web 项目中使用 Entity Framework 进行了一些研究之后，普遍的共识是每个请求应该只有一个 DbContext/ObjectContext。因此，为了为每个请求创建和处理单个上下文，我编写了一个将 DbContext 注入(inject)到 HttpContext 中的 HttpModule。

public class DbContextModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.BeginRequest += context_BeginRequest;
        context.EndRequest += context_EndRequest; 
    }

    public void Dispose()
    {
    }

    private void context_BeginRequest(object sender, EventArgs e)
    {
        HttpApplication application = (HttpApplication)sender;
        HttpContext httpContext = application.Context;

        httpContext.Items.Add(Repository.ContextKey, new ProjectEntities());
    }

    private void context_EndRequest(object sender, EventArgs e)
    {
        HttpApplication application = (HttpApplication)sender;
        HttpContext httpContext = application.Context;

        var entities = (ProjectEntities)httpContext.Items[Repository.ContextKey];

        entities.Dispose();
        entities = null;

        application.Context.Items.Remove(Repository.ContextKey);
    }
}

接下来是 Repository 基类。请注意，构造函数利用了上面 HttpModule 中注入(inject)的 DbContext

public abstract class Repository<T> : IRepository<T> where T : class, new()
{
    protected Repository()
    {
        if (HttpContext.Current == null)
        {
            throw new Exception("Cannot create repository - current HttpContext is null.");
        }

        _entities = (ProjectEntities)HttpContext.Current.Items[Repository.ContextKey];

        if (_entities == null)
        {
            throw new Exception("Cannot create repository - no DBContext in the current HttpContext.");
        }
    }

    private ProjectEntities _entities;

    public T Add(T item)
    {
        _entities.Set<T>().Add(item);
        _entities.SaveChanges();

        return item;
    }

    public T Get(object id)
    {
        return _entities.Set<T>().Find(id);
    }

    public T Get(Expression<Func<T, bool>> predicate)
    {
        return _entities.Set<T>().AsQueryable().FirstOrDefault(predicate);
    }

    public IQueryable<T> GetAll()
    {
        return _entities.Set<T>().AsQueryable();
    }

    public IQueryable<T> GetAll(Expression<Func<T, bool>> predicate)
    {
        return _entities.Set<T>().AsQueryable().Where(predicate);
    }

    public void Update(T item)
    {
        _entities.Entry(item).State = EntityState.Modified;
        _entities.SaveChanges();
    }

    public void Delete(T item)
    {
        _entities.Set<T>().Remove(item);
        _entities.SaveChanges();
    }
}

还有一个简单的实现示例...

public class AdminRepository : Repository<Admin>
{
    public Admin GetByEmail(string email)
    {
        return Get(x => x.Email == email);
    }
}

BLL

业务逻辑层封装了所有的业务逻辑。为了保持约束，我编写了这样的基本“逻辑”类:

public abstract class Logic<TRepository> where TRepository : class, IRepository, new()
{
    private static Expression<Func<TRepository>> _x = () => new TRepository();
    private static Func<TRepository> _compiled = _x.Compile(); 

    protected Logic()
    {
        Repository = _compiled();
    }

    protected internal TRepository Repository { get; private set; }
}

构造函数会自动创建所需的 Repository 类，因此子类中不需要额外的代码来实例化存储库。这是一个简单的实现示例

public class AdminLogic : Logic<AdminRepository>
{
    public Admin Add(Admin admin)
    {
        return Repository.Add(admin);
    }

    public Admin Get(object id)
    {
        return Repository.Get(id);
    }

    public Admin GetByEmail(string email)
    {
        return Repository.GetByEmail(email);
    }

    public IQueryable<Admin> GetAll()
    {
        return Repository.GetAll();
    }

    public void Update(Admin admin)
    {
        Repository.Update(admin);
    }
}

这个例子更多的是对 DAL 存储库的传递，但稍后添加业务逻辑不会有问题。我选择从 BLL 返回 IQueryable，因为我们正在使用一些需要 IQueryable 才能延迟执行的第三方工具。

项目(MVC项目)

现在终于可以看到一个简单的 Controller 操作了:

public ActionResult Index(int? page)
{
    // Instantiate logic object
    AdminLogic logic = new AdminLogic();

    // Call GetAll() and use AutoMapper to project the results to the viewmodel
    IQueryable<AdminModel> admins = logic.GetAll().Project().To<AdminModel>();

    // Paging (using PagedList https://github.com/TroyGoode/PagedList)
    IPagedList<AdminModel> paged = admins.ToPagedList(page ?? 1, 25);

    return View(paged);
}

一切正常，测试表明 EF 上下文已妥善处理，整体速度良好。

这是解决这个问题的好方法吗？

感谢您的宝贵时间。

Answer 1

我认为如果你打算使用存储库模式，你应该将你的存储库视为 aggregates 对我来说，做一个存储库可以有一定程度的抽象，这很好但这样做可能导致存储库成为实体以中心为中心，有时这使得与属于同一聚合根的其他对象通信变得困难。

我前段时间遇到过这样的困境，我最终没有使用存储库 (T)，而是使用了“通用存储库”中的方法 (T)，这让我更容易对属于聚合的其他对象进行操作root (我这样做是因为它适合我，但这并不意味着它适合你，我把这个例子放在 table 上只是为了让你考虑它)，你可以看看 this quesion和我发现非常有趣的 this article。

Jeremy Miller 谈论如何实现 IRepository:

public interface IRepository { // Find an entity by its primary key // We assume and enforce that every Entity // is identified by an "Id" property of // type long T Find<T>(long id) where T : Entity; // Query for a specific type of Entity // with Linq expressions. More on this later 
IQueryable<T> Query<T>(); 
IQueryable<T> Query<T>(Expression<Func<T, bool>> where); // Basic operations on an Entity 
void Delete(object target); 
void Save(object target); 
void Insert(object target); 
T[] GetAll<T>(); }

这与您在 repo 中所做的非常相似。

可能，我认为还需要 2 层(取决于您的要求)，一层用于 services 以处理应用程序中的常见操作或操作，另一层可能用于组件(电子邮件、日志、缓存管理器、密码学、助手)等)

关于您如何处理 BL 的逻辑，在我看来有点矫枉过正，实际上您是在将存储库耦合到逻辑中，我个人认为这不太好。

尝试在您的应用程序中实现 Dependency Injection，因为您将从中获得很多好处。

假设您要创建一个 UserService，它具有您的 BL 的登录方法

public class UserService:IService {
    public UserService(IUserRepository, IMailer, ILogger){
      // for example you can follow the next use case in your BL
      // try to login, if failed reteat after 3 time you block the accunt and send a mail

    }

   public bool login(string username, string password){
   }

}

然后您可以在您的 Controller 中实现该服务(如果您使用的是容器并仅调用登录服务，则将其注入(inject)构造函数)这将使您的实现更加清晰

public ActionResult Index(){
  //then you're going to be able to use  _userService.login()
}

这样你就会有一个 loosely coupled application ，理论上会更容易维护。

只是我的两分钱