四：MVC模式

标签：数据访问层   sendemail   size   domain   依赖项   简单的   eth   实现   组件开发   

理解MVC模式

模型（Model）:含有或表现用户进行操作的数据，模型可以是简单的视图模型，他们只表现视图和控制器之间的数据传递。也可以是域模型，包含业务领域的数据，以及处理这些数据的操作，转换和规则。

视图（View）：将模型的某些部分渲染成用户界面

控制器（Controller）:处理传入请求，执行模型操作，渲染给用户视图。

模型是程序工作的定义，不涉及UI也不涉及请求处理。

MVC架构的每一部分都有良好的定义和自包含，这称为关注分离。

域模型

MVC最重要的部分是域模型，对于应用程序必须支持的业务或活动中存在的现实实体，操作，规则等。通过对他们进行标识的方法创建模型，称为于模型（Domain）。

域模型一般是一组C#类（类，结构），统称为域类型（Domain Type）。域的操作由域类型中的方法实现，域规则表示成这些方法的逻辑。或者通过C#的注解属性实现。创建一个域类型的实例来表现特定的数据片段时，创建了域对象。域模型通常是持久化的，且一直处于活动状态。最常见的实现方式是关系数据库。

总结就是域模型是程序中业务数据及处理的唯一和权威的定义。

MVC的ASP.NET实现

 其他模式

智能UI模式：主要是面向页面的组件开发，组件比较智能，比如拖拽按钮按键组件就可以直接设计出页面。比较有名的是Winodws Form和ASP.NET Web Form。优点是开发快，上手容易，适合小项目。缺点是不易维护和拓展，没有关注分离，业务和UI组合在一起，前段后端结合太紧密。

模型-视图架构：相当于智能UI模式所有的地方都有可能有业务逻辑。模型视图模式把业务逻辑抽取出来形成一个独立的域模型。这种做法数据过程和规则都集中在一个单独的部分中。但是问题是UI和模型仍然联系的太紧密。模型通常有大量的数据访问代码。

三层架构：比模型视图模式更进一步的优化是，从模型中抽取一层叫做数据访问层（DAL）。三层架构是应用程序中使用最广范的模式，提供了较好的分离而且不复杂。三层架构已经和MVC模式非常相像了，但是差别是UI层和模型之间仍然耦合太强。也就是说没有完全分离。MVC模式是每层之间完全分离的。

松耦合组件

最理想的应用是每个组件都不了解其他组件，仅仅是通过抽象的结构和抽象类来处理其他组件。这种称为松耦合。

实例：一个能够发送邮件的组件MyEmialSender，一个通用的接口IEmailSender，一个具体的实现他组件如PasswordResetHelper用来重置密码和发送邮件。

实现的代码结构如下

    public class PasswordResetHelper
    {
        public void ResetPasswor() { 
            IEmailSender mySender=new MyEmailSender;
            mySender.SendEmail();
        }
    }
    public interface IEmailSender
    {
        void SendEmail();
    }
    public class MyEmailSender:IEmailSender
    {
        public void SendEmail()
        {
            //Send Emial
        }
    }

结构图如下

问题：三个类和接口直接仍然紧密结合。

依赖注入控制反转：一种方法，能够直接获取某个接口的对象，又不必创建该对象。

1：打断声明和使用依赖。接口的使用类PasswordResetHelper不再有MyEmailSender的任何知识，仅仅依赖了接口。也就是说不再了解接口的任何实现。

    public class PasswordResetHelper
    {
        private IEmailSender mySender;
public PasswordResetHelper(IEmailSender senderParam)
        {
            mySender = senderParam;
        }
        public void ResetPasswor() { 
            mySender.SendEmail();
        }
    }
    public interface IEmailSender
    {
        void SendEmail();
    }
    public class MyEmailSender:IEmailSender
    {
        public void SendEmail()
        {
            //Send Emial
        }
    }

2：注射依赖项

在创建PasswordResetHelper的实例时，注入声明的依赖项，称为依赖项注入。

这种依赖项是在运行时才被注入到该类中，也就是说在PasswordResetHelper实例期间才会创建IEmialSender接口的实例类实例，并传递给PasswordResetHelper构造器，PasswordResetHelper与依赖的接口实现之间不存在编译依赖项。

3：依赖项注入容器

虽然实现类PasswordResetHelper已经实现了弱耦合，不需要在该类中定义接口实现，但是在其他地方仍然需要类似IEmialSender sender=new MyEmialSender()，然后有Helper=new PasswordResetHelper(sender)的语句。

依赖项注入容器（DI容器），他在实现类声明的依赖项和解决依赖项类之间充当中间件角色。

这种容器的作用就是请求接口，返回接口的实现类，如请求IEmialSender，则返回MyEmailSender实例。这种容器的作用就是程序不再需要手动使用new关键字创建对象了。而且完全依赖DI容器。

现在已经有很多比较好的DI容器，如微软的Unity。还有Ninject等。

四：MVC模式

标签：数据访问层   sendemail   size   domain   依赖项   简单的   eth   实现   组件开发   

原文地址：https://www.cnblogs.com/yuanhaowen/p/9875926.html