基于spring framework 的分层管理.docVIP

基于Spring Framework 的分层管理 一个分层系统是按照层次来组织的，每一层为在其之上的层提供服务 Spring是一个解决了许多在J2EE开发中常见的问题的强大框架。 Spring提供了管理业务对象的一致方法并且鼓励了注入对接口编程而不是对类编程的良好习惯 当然，即使不分层，也能做出软件来，但我们应该思考怎么做才能最好？如果说分层不好，那么不分层的优势又在哪里呢？？如果说分层有性能的损耗，那么性能损耗在哪里呢？？如果不分层，软件工程思想中的“分而治之”的原则启不受到了质疑？ 有人说，分层是为了减少代码量，如果分层是为了减少代码量，那怎么能减少，代码的重用也许会减少一些，但是程序更多的是业务，我们关心的也只是业务，试问分层的意义就是为了减少代码量？ 以下是我的观点：我的一般分层思想是：action、service、dao。如果将来业务有什么变动，只需要关心service就可以了，有人问为什么。如果你说dao经常需要变动，那意味着你数据库经常需要变动，很显然，是你设计有问题；如果你说数据库连接之类的异常，那是你应该怀疑你自己的编程能力，因此dao是不会有变化的。在看action，action就是一个控制器，调用service和将service处理的结果返回前台，会改变吗？显然也不会。最后就是service，如果出问题，基本上可以直接定位到这里。如果不分层，那将会是灾难性的后果。o:p/o:p 我们经理的观点做web开发很简单，提交标单-〉响应-〉后台处理-〉返回。难道真的就这么简单吗？还认为使用一个框架之前必须知道他好在哪里。以下是我的看法： 如果web开发真的那么简单，要这些框架做什么？如果你能在不使用这些框架的情况下开发出自己的好框架而且项目能按时完成，如果你能说你能做到，那恭喜你，你可以不用。如果你在使用每一个框架之前都要说他好在哪里，那你还是不要用好了。早期CGI出来的时候，人们觉得他好；后来servlet出来的时候，觉得编程简单，否定了CGI；再后来JSP出来了，可以在页面写代码，避免了很多重复性的工作，于是否定了servlet；再后来自定义标签出台，觉得在JSP写太多java代码，不太好；后来看到ASP.NET的组件化技术很好，于是JSF出来了，人们说他好；再后来Spring MVC框架设计的完美，说他也很好；再后来webwork和servlet API相分离，又说他好；最近struts2流行起来，又说他好。如果当你能说出他到底好在哪里，也许这个技术已经不再是他的核心优点。 我认为实践是检验真理的唯一标准，既然有很多人有成功的案例，我们为什么不去使用这个东西。不要忘记，生产率是我们一直追求的目标。但是不排除市场上有炒作的成分，比如说dojo。这个东西你要是说他的优点，你最少可以说出50个，但是谁在实际项目中使用？也许有，但至少我没有看到是怎么用的，我尝试过dojo的0.4版本，性能的问题实在叫人无法忍受。我觉得dojo就有市场炒作的成分。比如说hibernate，也许有很多人知道他的优点，即使你不知道，你完全可以使用，因为成功的案例太多了，性能更是没得说。如果你认为hibernate不应该使用，那EJB3.0你是不是也觉得不应该使用了呢？ 总之我的观点就是：软件分层是必须做的。至于框架，不应该问用不用，而应该问用什么？要选用实践检验过的框架，毕竟实践是检验真理的唯一标准。 MVC与三层架构的区别 在CSDN和园子里有朋友谈到三层与MVC的区别，以前也有人抛出这个问题，本人对来公司面试的朋友也偶乐会提这方面的问题。 　　那么我也来讲讲我对这两者的理解吧。　　首先对这个题目，本身是存在问题的，“XX结构”与“XX模式”的区别?请问中国社会制度与美国人生活方式有什么区别?　　这两者本身讲的是不同方向与角度的问题，在实际应用中他们的确存在一些相似的特点，在很多书籍中也没有深入讲解，以致于造成困惑，为了更好的理解他们，姑且来说说区别吧。　　首先N层结构是一种软件抽象的层次结构，是对复杂软件的一种纵向切分，每一层次中完成同一类型的操作，以便将各种代码以其完成的使命作为依据来分割，以将低软件的复杂度，提高其可维护性。一般来说，层次之间是向下依赖的，下层代码未确定其接口(契约)前，上层代码是无法开发的，下层代码接口(契约)的变化将使上层的代码一起变化。三层结构是N层结构的一种，是人产在长时间使用中得出来的一种应用场合广泛的N层结构，被当作一种典型的软件层次结构而广为流传甚至写入教科书。　　MVC模式是一种复合设计模式，一种在特定场合用于解决某种实际问题来得出的可以反复实践的解决方案。巧合的是他也有三个事物组成，于是乎人们就有了一种想当然的对应关系：展示层-View;业务逻辑层-