3

我真的很困惑，我从“Apress pro Asp.net Mvc 4”一书中了解到，Mvc 4 的最佳模式是依赖注入，（将数据库的模型数据等......放在另一个项目中（域）然后为这些接口创建接口和实现，然后使用 Ninja 将其连接到控制器。

并且所有连接到 db 仅来自数据层解决方案，viewModel 中的 web 解决方案中唯一的模型

控制器

public class ProductController : Controller
{

    private IProductRepository repository;

    public ProductController(IProductRepository productRepository)
    {
        this.repository = productRepository;
    }
    ....
}

和忍者

 ninjectKernel.Bind<IProductRepository>().To<EFProductRepository>();

另一方面，在我的上一份工作（网站管理员）中，公司为 mvc 项目使用了另一种模式（我现在正在使用这种模式）。

这些项目仅使用一种解决方案并使用静态类来处理数据层

我不喜欢依赖注入，这太复杂了，通过'f12'你只能看到接口而不是具体类

一些问题：

  1. 哪种模式更适合性能（快速网站）？
  2. 不好用“public Db db = new Db();” 在控制器中，而不是仅在域层（解决方案）中使用它？
  3. 使用依赖注入有什么好处？使用我的模式还不错吧？
  4. 将项目拆分为数据层的 2 个解决方案有什么好处？

例子：

 public class LanguageController : AdminController
    {
         public Db db = new Db();

        protected override void Dispose(bool disposing)
        {
            db.Dispose();
            base.Dispose(disposing);
        }

        //
        // GET: /Admin/Language/
        public ActionResult Index()
        {
            return View(db.Languages.ToList());
        }

        [HttpPost, ActionName("Delete")]
        [ValidateAntiForgeryToken]
        public ActionResult DeleteConfirmed(short id)
        {
            Language language = db.Languages.Find(id);
            db.Languages.Remove(language);
            db.SaveChanges();
            return RedirectToAction("Index");
        }
    ...
}
4

1 回答 1

6

哪种模式更适合性能（快速网站）？

无法回答。在这些方法中的任何一种中，您都可能有非性能代码。不要试图过早地优化性能，优化干净且可支持的代码，并解决在实际场景中实际观察到的性能瓶颈。

不好用“public Db db = new Db();” 在控制器中，而不是仅在域层中使用它（解决方案）

这是一个分离关注点和隔离依赖关系的问题。如果您的控制器在内部实例化与数据库的连接，则该控制器只能在该数据库的上下文中使用。这将使控制器的单元测试变得非常困难。这也意味着替换数据库意味着修改控制器，在这种情况下不需要修改。

依赖注入框架只是解决依赖倒置原则的一种方式。这个想法是，如果对象 A（控制器）需要对象 B（数据库对象）的实例，那么它应该要求将实例提供给它，而不是在内部实例化它。这里的直接好处是对象 B 可以只是一个接口或抽象类，可以有许多不同的实现。只要满足相同的可观察行为，对象 A 不应该关心给予它的实现方式。

通过反转依赖关系（无论您是否使用依赖注入框架），您可以从控制器中删除对数据库的依赖关系。控制器只处理客户端发起的请求。其他东西处理数据库依赖性。这使得这两个独立的对象更加便携和可重用。

使用依赖注入有什么好处？使用我的模式还不错吧？

看上面。依赖注入是一种实现依赖倒置的方法，这是本案例的核心目标。请注意，有几种不同的方法可以实现这一点。一些框架更喜欢构造函数注入，一些支持属性/设置器注入等。我个人倾向于使用服务定位器模式，它具有能够抽象依赖注入器本身的依赖关系的额外好处。

如果您在使用它时遇到任何问题，那么使用您的方法只是“不好的”。有一些很好的模式可以解决各种问题，但是如果您的项目没有合法地存在这些问题，那么使用这些模式将是过度设计，实际上会损害代码的可支持性。所以，就像任何事情一样，“这取决于”。

将项目拆分为数据层的 2 个解决方案有什么好处？

两种解决方案？还是同一解决方案中的两个项目？（产生两个程序集。）优点是您可以重用一个而不依赖另一个。例如，在您发布的某些代码中，暗示了存储库模式。如果您有一个仅用于将存储库实现到后端数据的程序集，那么任何应用程序都可以使用这些存储库。相反，如果它全部直接在 MVC 应用程序中实现，那么其他应用程序就不能使用它，它与 MVC 应用程序紧密耦合。

如果您永远不需要重复使用该功能，那么这不是世界末日。如果您想重用该功能，将其分离成一个可移植的程序集，该程序集在内部隔离其依赖项将允许这样做。

于 2013-07-18T15:32:47.473 回答