•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