IOC个人 理解

   

今天组内交流Spring.net，被队友吐槽表达不清晰。恩，确实表达能力不行，还是写下来吧。

首先，假设我们要在 UI项目中写一个窗体，用来显示和修改系统用户，可能会有下面的代码。

1. public partial class FrmUser : Form
2. {
3.    
4.     UserBLL _userBLL=new UserBLL();
5.    
6.     public FrmUser()
7.     {
8.         InitializeComponent();
9.     }
10. .....
11. }

上面的代码乍看 没有问题，但实际上已经有了隐形的耦合。不管这里的UserBLL是NHiberate实现、EF实现、Linq2Sql…，总而言之！UserBLL已经悄悄的用自己的实现方式限制了FrmUser窗体，如果UserBLL的方法 中有用到第三方 Dll，那UI项目也要引用 。这样写最大的问题是：FrmUser的功能都依赖于UserBLL实现，即UI项目依赖于BLL项目，假如现在的UserBLL是EF实现的，有一天我新建了一个NHUserBLL，用NH实现，必须将UI项目所有的UserBLL替换成NHUserBLL.........

 

实际上UI项目就像是客户，客户只提需求就行了，不关注具体实现方式（到底是EF还是NHiberate实现数据访问）。在代码上，我们可以定义一个IUser做为UI项目所提出的需求，这样就实现控制反转了：不管你的BLL是用EF还是NH，反正要想给调用，就先实现我的接口IUser~~~~~~~~~~~~当然，我们不会让让BLL项目引用UI项目，所以IUser会放在另一个新建项目里。

让后代码就会变成这样

1. public partial class FrmUser : Form
2. {
3.  
4.     private IUserBLL _userBLL=new UserBLL();
5.  
6.     public FrmUser()
7.     {
8.         InitializeComponent();
9.     }
10.     .......
11. }

吗？当然不是！！！如果这样写，UI项目还是有对BLL项目的依赖。解决的办法有两个：工厂模式和IOC框架，上代码：

 

1. public partial class FrmUser : Form
2. {
3.  
4.     private IUserBLL _userBLL=DataAccess.CreateUserBLL();//工厂模式
5.  
6.     public FrmUser()
7.     {
8.         InitializeComponent();
9.     }
10.     .......
11. }

大名鼎鼎的工厂模式，没什么好说的，核心思想是把依赖都集中到了工厂上。

 

1. public partial class FrmUser : Form
2. {
3.  
4.     public FrmUser()
5.     {
6.         InitializeComponent();
7.     }
8.  
9.  
10.     public List<User> GetUser()
11.     {
12.          IApplicationContext ctx = ContextRegistry.GetContext();//初始化IOC容器
13.          IUserBLL _userBLL=ctx.GetObject("UserBLL") as IUserBLL;;
14.     }
15.     .....
16. }

IOC思想，Spring.net实现，反正是解耦了，原理和教程网上很多~~~~~~~~~~~~~~~~~~