前五篇已经把Models 介绍完啦，从今天开始我们要介绍“V”&"C"啦。现在我们还是从MVC的定义说起，其实MVC最大的好处就是M层（脱离V与C）可以独立单元测试，真正做到了数据层与表现层（晕，不知道有没有这个说法）的分离。所以，我们可以完全不考虑界面把M层完成。但是，现在的M层并不是已经定型。我们在写“V”与“C”的时候，如果发现还需要有新的功能，完全可以回过头来改动M层。其实，框架搭好啦，修改也是非常容易的。
说明一下，我们现在暂不考虑权限控制，最后再来完成。
闲话少说，我们现在就动工吧。
现在我们又要用到一个新概念，那就是 DI和IOC，如果疑惑的“哇，这是啥啊？”，你可是要好好的百度谷歌一下啦。看看这个是否对你有帮助？http://www.cnblogs.com/PeterWang/archive/2008/09/07/1277967.html  摘自上面这个链接的一段话：
DI和IOC是一直很流行的架构设计思想和方法，IOC是将对象内部的依赖解藕 将原先内部的控制反转给了类之外 又称Dependence Injection 。IOC或DI的核心思想在于提供一个更加简单的机制来规定组件之间的依赖关系（一般涉及到对象的合作），并且在它们生命周期中对依赖关系进行管理。 IOC提供了这样的服务，使一个组件能够在它的生命周期中访问它的依赖和服务。总的来说，IOC能够被分解为两种字类型：依赖注入和依赖查找。从这个意义 上来说，当我们谈及DI的时候总是在谈IOC，但是当说到IOC的时候却不一定涉及DI. 需要进一步清楚知道他们的原理和理论请参考其它文章。
还有一段来历不明的话，希望帮助你的理解：
《两个个很形象的依赖注入的比喻》
何谓控制反转（IoC = Inversion of Control），何谓依赖注入（DI = Dependency Injection）？一直都半懂不懂，今天看到两个比喻，觉得比较形象。
IoC，用白话来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓"控制反转"的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。
正在业界为IoC争吵不休时，大师级人物Martin Fowler也站出来发话，以一篇经典文章《Inversion of Control Containers and the Dependency Injection pattern》为IoC正名，至此，IoC又获得了一个新的名字："依赖注入 （Dependency Injection）"。相对IoC 而言，"依赖注入"的确更加准确的描述了这种古老而又时兴的设计理念。从名字上理解，所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中。
一：
再看上例中，笔记本电脑与外围存储设备通过预先指定的一个接口（USB）相连，对于笔记本而言，只是将用户指定的数据发送到USB接口，而这些数据何去何从，则由当前接入的USB设备决定。在USB设备加载之前，笔记本不可能预料用户将在USB接口上接入何种设备，只有USB设备接入之后，这种设备之间的依赖关系才开始形成。
对应上面关于依赖注入机制的描述，在运行时（系统开机，USB 设备加载）由容器（运行在笔记本中的Windows操作系统）将依赖关系（笔记本依赖USB设备进行数据存取）注入到组件中（Windows文件访问组件）。这就是依赖注入模式在现实世界中的一个版本。
很多初学者常常陷入"依赖注入，何用之有？"的疑惑。想来这个例子可以帮助大家简单的理解其中的含义。依赖注入的目标并非为软件系统带来更多的功能，而是为了提升组件重用的概率，并为系统搭建一个灵活、可扩展的平台。将USB接口和之前的串/并、PS2接口对比，想必大家就能明白其中的意味。
二：
首先想说说IoC（Inversion of Control，控制倒转）。这是spring的核心，贯穿始终。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。这是什么意思呢，举个简单的例子，我们是如何找女朋友的？常见的情况是，我们到处去看哪里有长得漂亮身材又好的mm，然后打听她们的兴趣爱好、qq号、电话号、ip号、iq号………，想办法认识她们，投其所好送其所要，然后嘿嘿……这个过程是复杂深奥的，我们必须自己设计和面对每个环节。传统的程序开发也是如此，在一个对象中，如果要使用另外的对象，就必须得到它（自己new一个，或者从JNDI中查询一个），使用完之后还要将对象销毁（比如Connection等），对象始终会和其他的接口或类藕合起来。
那么IoC是如何做的呢？有点像通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所。婚介管理了很多男男女女的资料，我可以向婚介提出一个列表，告诉它我想找个什么样的女朋友，比如长得像李嘉欣，身材像林熙雷，唱歌像周杰伦，速度像卡洛斯，技术像齐达内之类的，然后婚介就会按照我们的要求，提供一个mm，我们只需要去和她谈恋爱、结婚就行了。简单明了，如果婚介给我们的人选不符合要求，我们就会抛出异常。整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制。Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。对于某个具体的对象而言，以前是它控制其他对象，现在是所有对象都被spring控制，所以这叫控制反转。如果你还不明白的话，我决定放弃。
对了，还有这个：http://www.cnblogs.com/terrylee/archive/2006/04/17/377018.html
为什么要IOC，还是为了降低耦合性。
好，我们现在就开始应用IOC模式啦！

 跟我学MVC系列（Repository模式、LINQ、EF、IOC框架Castle、JQuery、AJAX）（一）数据库建模
跟我学MVC系列（Repository模式、LINQ、EF、IOC框架Castle、JQuery、AJAX）（三）Models（ORM、Repository模式、分页）

我们将以实例为主，关于MVC的具体理论请在博客园中搜索，到处都有。
在设计好数据库之后，打开VS2008,选择创建项目“ASP.NET MVC WEB APLLICATION”，系统会自动生成一个MVC框架，我们在这个MVC框架的基础上开始我们的项目。创建后，我们会不得不佩服微软的贴心，她已经给我们自动生成了一个MVC框架程序，如下图：

看看，是不是“M”“V”“C”都有啦，而且JQUERY 和AJAX也给引入了，实在是让人省心不少啊
运行之后，界面如下：

，不错吧，OK，下面我们开始写入我们自己的东东啦。
首先，我们看到"Mondels"在“Scripts”文件夹下面，看着让人不爽，应该与“M”“V”并列才对啊，所以我们把它移到根目录下面，如下图：



因为我们要用到Repository模式，希望大家对此也要有一定的了解，以下是网友的话：
“

在《企业架构模式》中，译者将Repository翻译为资源库。给出如下说明：
通过用来访问领域对象的一个类似集合的接口，在领域与数据映射层之间进行协调。

在《领域驱动设计：软件核心复杂性应对之道》中，译者将Repository翻译为仓储，给出如下说明：
一种用来封装存储，读取和查找行为的机制，它模拟了一个对象集合。

使用该模式的最大好处就是将领域模型从客户代码和数据映射层之间解耦出来。

”摘自http://www.cnblogs.com/carysun/archive/2009/03/20/repository.html
具体请各位百度一下吧。

现在开始创建所需的文件夹，“Models”文件夹是提供所有实体类的接口，比如“用户”、“账目”等，以及对这些实体类的所有操作功能（增删改查），于是我们首先在“Models”文件夹下创建三个接口，它们分别是"IUser" "IAccount" "IAccountType"作为用户类、账目类和账目类型类的接口，代码如下：

以上就是三个接口啦，具体内容一看明了.OK,现在还在要Models文件夹下建二个文件夹，它们分别是“User” "Account"，这两个文件夹下主要是具体功能的实现。Models里面的东东是不与数据库直接打交道的，我们使用Repository模式来提供与数据库直接打交道的增删查改的操作，Models直接使用Repository提供的基本功能。好了，我们先把Models放在这儿不管，下面来设置Repository模式，首先创建一个Repository文件夹（与Models平级），如下图：


，要与数据库打交道，我们就想到了EF这个ORM，关于EF，请参考：http://www.cnblogs.com/xray2005/archive/2009/05/07/1452033.html ,
打开“服务器资源管理器”，建立与我们创建的数据库的连接，如下图：



,然后，在“Repository”文件夹下面添加“ADO.NET Entity Data Model”,我们命名为“AccountEDM”,
然后选择“从数据库生成”，把我们建立的三个表全选，系统就自动生成了一个EF，如下图：

这一篇就介绍到这儿，下一篇我们具体介绍Repository模式与EF结合在ASP.NET MVC中的应用。
欢迎批评指正。