四:MVC模式

理解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等。

 

转载于:https://www.cnblogs.com/yuanhaowen/p/9875926.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值