我喜欢struts，喜欢ibatis，喜欢spring，但我却喜欢.net，这实在是件很矛盾的事情。.net很好用，但在做项目的过程，总觉得缺少了点什么，对了，是框架。在java的世界里，有着许多成熟优秀的框架，但.net的框架，可选择的实在很少。在盼星星盼月亮的漫长过程里，终于盼到了Asp.net MVC，恕我不才，看来看去，都觉得这Asp.net MVC用起来实在是麻烦。我还是喜欢使用struts，尽管我很烦恼那些配置文件，但配置文件确实给我们带来了很多的好处。能轻松的扩展，轻易的修改。不过tomcat实在很垃圾，修改了配置文件居然还要重启。我喜欢.net，喜欢c#，喜欢Visual Studio，我觉得c#使用起来很自然，很舒服。然而，我害怕面对一张复杂的表单，想要获取几十个，上百个数据项实在是种痛苦。我经常的想，要是.net也有个struts的框架该多好啊，既然没有，那么，就让我来设计一个吧。

当然，struts的设计并不是为了仅仅解决获取表单数据麻烦的事情，要是仅仅如此，那就实在是太大题小作了，封装表单数据只是它的功能的开始，有了数据还需要对它们进行验证。有些人可能觉得，数据验证我都在前台进行了，后台就不需要对数据再进行验证，我只想说，这实在是件很危险的事情。我不打算讨论前台数据验证可不可靠，我个人觉得，它是不可靠的，即使它可靠，但是多一层的验证不是更确保系统的安全吗？验证完数据之后就是执行业务逻辑了，然后就是页面的跳转或者返回请求的页面。Struts让这个流程自动地执行了，我们所要做的，只是往Validate和Execute这两个方法中添加逻辑代码。根据ISO的管理理念，员工做的事情越单一，熟练度也就越高，出错的几率就越小。struts的设计，是完全符合软件工程的设计思想的。

配置文件是struts核心的一部分，许多人都不喜欢使用配置文件，我也是其中一个。记得刚开始接触struts的时候，对它的配置文件实在是很烦，但慢慢地，了解了配置文件的作用之后，就喜欢上使用配置文件了。配置文件在项目中的作用是毋庸置疑的，在大型的项目中尤其重要。需求是不断地改变的，但我们的程序可不能老跟着需求变，即使老板吃得消，员工也吃不消啊。改变一个页面的业务逻辑，只需要在配置文件中修改一下action的配置就可以了，其它的代码都不需要改变。说到配置文件，它还有一个很重要的作用，那就是“控制反转”或者“依赖注入”，其实我也搞不清这两个词语之间是什么关系。不过，也没必要在这些文字间咬文嚼字，就用IOC来代替它们好了。在开发过程中，经验会遇到一个类里面包含另一个类的实例，如：

那么，在上面的代码中，B将依赖于A，也就是说，没有A，B就无法正常的执行。这样，B和A就产生了耦合。说得再明白一点，如果B的业务逻辑需要改变了，不想使用A，而是使用C，那么，就需要修改B的代码，还要重新编译，这对于大型的系统来说，需要起来代价是很大的。为了达到高内聚低耦合的需要，我们应该让B依赖于抽象而不是具体。比较常用的方法是使用工厂模式，如：

那么需要改变时，只需要发动工厂就行了，这大概就是平时所说的控制反转吧，由以前的修改B类转为修改工厂类。但是还是需要修改代码，当需要扩展新的类时也要修改工厂类，这明显是换汤不换药嘛，依赖注入也就应运而生了。

对于依赖注入，我的感觉是就像是打针，需要什么就往里面注射什么。那么针在哪里？当然是在配置文件里了。要实现依赖注入，得修改一下B类，添加Setter方法。

此时，B类中A属性就可以通过配置文件来注入了，想要A就注入A，想要C就注入C，多方便啊。注入，你可以这样理解：类是一个封装体，就把它想象成一个空心的球体吧，Setter方法相当于这个球体的一个小孔，注入也就是把它需要的东西通过这个小孔往里面塞。

说了这么多，其实都是在为我下一篇的文章作准备。下一篇文章将发布nstruts2.0，它比先前发布的nstruts1.0有了很大的改进，增加了许多新的元素，并且还支持依赖注入，注入的数据可以是对象，常量，还有集合。这些功能已经能完全满足项目开发中大部分的需求了。同时，nstruts2.0将会是个很好的学习实例，它设计的思路比较清晰和简单，对象框架设计感兴趣的朋友都会有或多或少的帮助。在发布之前，大家可以先看下我先前发布的nstruts1.0，了解一下大概。

地址：发布.net版的struts---nstruts1.0