我应该在 MVC 编码中使用什么标准

Question

根据here 提到的答案，我知道我应该将业务逻辑放在模型本身中，而在我的程序中，我直接在控制器的操作中使用 EF，例如从直接数据库我正在做以下事情：

public ActionResult CarList()
{
    using(var _db = new CarRentEntities())
    {
         var result = _db.Cars.Where(m=>m.Active);
         return View(result);
    }
}

如果我在控制器或模型中使用上述代码，对我的网站性能有什么影响？

我应该使用哪种方法？例如，如果我想与一个团队合作，是否有我应该遵循的标准来分隔代码，请指教

对于使用存储库模式：我读到我们不应该使用如果提到的例子 here ，我将复制一些提到的内容：

不将存储库模式与实体一起使用的唯一最佳理由 框架？实体框架已经实现了存储库模式。 DbContext 是您的 UoW（工作单元），每个 DbSet 都是存储库。 在此之上实现另一层不仅是多余的，而且 使维护更加困难。

如果我的数据库包含以下表格：Manufacturers、Cars、Rent、Clients，则租金等级为在 Clients 和 Cars 之间具有 2 个外键并包含其他详细字段的表。

如何处理需要从 2 个不同的存储库 Cars 和 Clients 获取数据以根据用户输入的搜索条件显示租赁网格的 Rent 对象，如果我将使用存储库 Cars 和 Clients ，它们有自己的自己的 dbContext，BOOM我的脑袋看不懂这个技巧，请指教

Answer 1

通常模型是一个“单元”——即它是您要显示的数据的模型。控制器是一个“集成器” - 即它将呈现网页所需的各种资源汇集在一起​​​​。您可能希望创建一个执行类似操作的数据库门面类；

public ActionResult CarList()
{
    using(var carStore = new Factory.CreateCarStore())
    {
         var result = carStore.GetActiveCars();
         return View(result);
    }
}

将您的数据库访问与您的 Web 控制器分开（这也将使其更具可测试性，因为您可以替换不同的 CarStore 实现（即测试 XML 数据集）用于测试目的。

Answer 2

您的问题的答案是，它不会真正影响性能，但随着应用程序变得越来越大，它肯定会成为可维护性方面的问题。您可以采用 SOLID 架构原则：SOLID architecture principles using simple C# examples。这使您能够开发高质量的软件。

您可以创建多层应用程序：

1. 接口层 - MVC 应用程序
2. 业务层 - 具有逻辑类的类库
3. 数据访问层 - 数据库上下文和存储库，CRUD 操作的工作单元
4. 共享层 - 日志记录、AppSettings、验证、实用程序、扩展、常量、枚举

让您的应用程序采用这种结构，您需要考虑控制反转、依赖注入等诸多因素，以确保松散耦合的类、简单的单元测试以及最重要的是一个可靠的应用程序。

您也可以阅读：Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application