asp.net - 选择哪种模式？ Asp.net Mvc 4

Question

我真的很困惑，我从《Apress pro Asp.net Mvc 4》这本书中了解到，Mvc 4的最佳模式是依赖注入(inject)，(将数据库的模型数据等放入...在另一个项目(域)中，然后创建接口(interface)和这些接口(interface)的实现，然后使用 Ninja 将其连接到 Controller ..

所有到数据库的连接都仅来自数据层解决方案，即 viewModel 中 Web 解决方案中的唯一模型

Controller

public class ProductController : Controller
{

    private IProductRepository repository;

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

和 Ninject

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

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

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

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

一些问题:

1. 哪种模式的性能更好(快速网站)？
2. 不好使用“public Db db = new Db();”在 Controller 中，而不是仅在域层中使用它(解决方案)??
3. 使用依赖注入(inject)有什么优点？使用我的模式也不错吧？
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");
        }
    ...
}

Answer 1

which patter is better for performance (fast website)?

无法回答。在这两种方法中，您都可能会遇到性能不佳的代码。不要尝试过早地优化性能，优化干净且可支持的代码并解决在实际场景中实际观察到的性能瓶颈。

is't good to use " public Db db = new Db();" in the controller, instead of use it only in the domain layer (solution)

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

依赖注入(inject)框架只是解决Dependency Inversion Principle问题的一种方法。 。这个想法是，如果对象 A( Controller )需要对象 B(数据库对象)的实例，那么它应该要求向其提供该实例，而不是在内部实例化它。这里直接的好处是对象 B 可以只是一个接口(interface)或抽象类，可以有许多不同的实现。对象 A 不应该关心给它哪个实现，只要它满足相同的可观察行为即可。

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

What is the advantages of using Dependency Injection? is't bad to use my pattern?

见上文。依赖注入(inject)是一种实现依赖反转的方式，这也是本例的核心目标。请注意，有几种不同的方法可以实现此目的。有些框架更喜欢构造函数注入(inject)，有些支持属性/ setter 注入(inject)等。我个人倾向于使用服务定位器模式，它的另一个好处是能够抽象依赖注入(inject)器本身的依赖关系。

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

What is the advantages of split the project into 2 solutions for the Data Layer?

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

如果您永远不需要重复使用该功能，那么这并不是世界末日。如果您想重用该功能，可以将其分离到一个可移植程序集中，该程序集在内部隔离其依赖项，这样就可以实现这一点。