•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
转载于:https://www.cnblogs.com/lzhp/archive/2013/01/24/2874731.html
