mvc简介以及DI实例

MVC架构模式

•Models，其中包含或代表用户使用的数据。他们可以是代表视图之间传输的数据和控制器简单的ViewModels（在音乐商店中用过的），也可以是域模型（在音乐商店中的ShoppingCart模型），其中包含一个数据业务领域以及操作、转换和规则操纵数据。

•Views，用于呈现用户界面模型的某些部分。

•Controllers，处理传入的请求，模型上执行操作，选择视图呈现给用户。

　　模型是应用程序工作的整体定义。在银行业的应用，举例，模型表示在银行的所有应用程序支持，如帐户，总帐，信贷限额的客户，以及可以使用的操纵模型中的数据，例如账户的存款和取款。模型还负责维护数据的整体状态和一致性；例如，确保所有交易都将添加到总帐上，而客户端不能撤回比他有权更多的或比银行的更多的钱了。他们定义的模型也不负责。模型不处理呈现ui 或处理请求-那是视图和控制器的责任。视图包含需要向用户显示的模型元素的逻辑，没什么更多。他们不能直接的认知模型并不能与以任何方式直接与模型沟通。控制器是视图和模型之间的胶水。从客户端的请求中来，并由控制器提供服务，如果需要，选择适当的视图，以显示给用户，让用户在模型上进行适当的操作。每个mvc体系结构是明确的和独立的，它是指分离关注点。模型中的数据操作的逻辑是只被包含在模型，显示数据的逻辑是在视图中，处理用户的请求和输入的代码只包含控制器。每个部分之间的明确分工，您的应用程序更易于维护和延长其寿命，无论它有多大。

关于DDD的知识实在是比较深奥，在此只留个链接以后查阅http://www.cnblogs.com/netfocus/category/361987.html

依赖注入

依赖注入就是使用接口作为构造函数的形参来构建类，从而到达了解耦的目的。下面是一个修改密码的例子，主要设计到两个类和一个接口。如图：

通过引入IEmailSender，我们就能够确保在PasswordResetHelper跟MyEmailSender之间没有直接的依赖关系。比如，我们可以用其他的实现了发送邮件的Provider来替换当前的MyEmailSender而不会对PasswordResetHelper造成影响，从这里也能够体会到松耦合的好处吧。但是如果用不好的话可能会成下面这种情况。

具体是怎么解决的直接看代码：

public class PasswordResetHelper
{
      private IEmailSender emailSender;
      public PasswordResetHelper(IEmailSender emailSenderParam) 
      {
           emailSender = emailSenderParam;
      }
      public void ResetPassword()
      {
          //邮件的详细配置...
          emailSender.SendEmail();
      }
}

在面向对象中，经常使用接口作为返回值类型或者是形参。

其它的例子可以参考http://www.cnblogs.com/mszhangxuefei/archive/2011/12/09/mvcnotes_8.html和http://www.cnblogs.com/mszhangxuefei/archive/2011/12/10/mvcnotes_9.html

下面把两篇源码附上：ninjectDemo