部署方便，包头只是声明，包体实际代码。

对于重要的存储过程我们建议从包中拿出来单独的进行编译。


一下部分为摘抄--
今天，和一个朋友聊天，他是做.NET开发的（PS:鄙人是 Java 的虔诚信徒），朋友说他们最近在做的一个项目，使用了400个左右的存储过程代码封装了整个逻辑!光是存储过程代码在50000行左右!由此引发了我对软件开发的一些思考，我在此只是抛砖引玉，欢迎大家参与讨论！

    现代软件开发为什么要分三层甚至n层，无非是为了实现“强内聚、松耦合”的目标，将软件“分而治之”，把问题划分开来各个解决，易于控制，易于实现组件重用，易于扩展和维护，易于分配资源。大大降低了开发和维护的成本，其优势不言而寓。

    以下是鄙人的一些愚见，有不对的地方望指正！

    1. 对于小项目，业务放存储过程里编程最简单，详细写好注释，避免数据从数据库到程序的来回传递，这也是存储过程的优点。
    2. 但是对于中大型项目，访问量很大，若将业务逻辑大量封装于存储过程中会导致数据库压力太大，中间层压力太小，资源闲置。这时就应该把业务放到中间层，中间层压力大的时候容易做服务器Cluster，做负载平衡。
    3. 做产品的时候，考虑到产品的移植性和安全性，应该尽量避免存储过程。
    4. 多人开发的时候，存储过程不是很方便做版本控制和管理。
    5. 关于Debug，调试不是很方便。
    6. 如果sp中有一大堆if, case, 然后每个begin  end之间有一大段处理, 甚至if case 还不断嵌套, 我认为这是在滥用sp, 这个应该是程序去完成的；    
      如果程序中从数据库中不断的拉数据和缓存数据,   结果就是为了几个表关联出点什么东西,   我认为是在滥用程序,   这个应该是sp去完成的

    7.存储过程的执行效率确实比较高，一些O/R mapping 框架如Hibernate则有性能瓶颈问题，用得不好会导致性能的下降，个人认为用ibatis 再在适当的时候结合使用存储过程，这样既可以兼顾OO的设计，又可以兼顾性能问题。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

对于开发者而言，耦合原则表示程序中单个的模块应该尽可能的独立。 
处理一个模块时，不应该依赖另一个模块的内部工作。 
内聚原则是指，在一个给定的模块内部，所有的代码应该只完成一个单个的目标。 
IT界有一句很著名的口号： 强内聚、松耦合 。 
即使是最初级的程序员，在常常的被教导中，他也了解了这句口号的含义：我们的程序要模块化，模块要完成明确的一组关联的服务功能，要求它的各部分是相关 的、有机组合起来是完整体（外部程序来看黑盒子），模块的内部各成分之间相关联程度要尽可能高（强内聚）；而模块与模块之间又要求是可分拆的、少依赖的 （松耦合）。 
人们易于实现强内聚的模块，例如：一个函数实现一个独立的功能，这就是强内聚。 
人们不易实现松耦合，因为，孤独的模块毫无意义，只有模块间的相互协调地工作，才能实现系统的目的。而对于模块间的相互关系的设计，没有一定的经验是难以 把握。耦合的强度依赖于：（1）一个模块对另一个模块的调用；（2）一个模块向另一个模块传递的数据量；（3）一个模块施加到另一个模块的控制的多少； （4）模块之间接口的复杂程度。等等。 
当然，“强内聚、松耦合”也是有矛盾的，如：内聚性越强，则要求的函数越多（每个函数只作一件“事”），这样，将它们组合成“大”的功能，也就越复杂，就 不可能达到松耦合。因此，应在二者之间作出平衡与折衷的选择，这也体现程序员的水平。从系统论的角度来看，系统是有层次的，即系统可以分为子系统，模块可 分为子模块，“强内聚、松耦合”的“度”的把握，应结合系统的次层性来考虑，即通常应在层次性上作出折衷，如：模块内子程序（下一个层次上）应共享数据 （有一定的耦合度），而减少全局变量能降低子程序性间的耦合性。 
面向对象的语言进一步强化了“强内聚、松耦合”，类的封装性既强调了相关内容（数据及其操作）的内聚，又强调了类的独立性和私密性。而类的继承性以及友元 等，就是在松耦合的原则下规范了类之间的关联关系。类与类之间通常通过接口的契约实现服务提供者/服务请求者模式，这就是典型的松耦合。 
“强内聚、松耦合”对于程序编写分工、程序的可维护性以及测试都有重要的关系，如：从设计角度来看，在“强内聚、松耦合”的指导下进行的设计得到的程序模 块，符合项目管理的WBS（工作分解结构）的要求，其相对独立的模块可以分配到具体的程序员进行开发，另外，程序编码外包也必须建立在这种原则的设计之 下；从程序生命期角度来看，它有利于提高程序质量，特别是方便于程序的日后维护，即程序模块的相对独立性是可维护性的保证；再从测试角度来看，符合“强内 聚、松耦合”的程序，易于对局部（模块）进行黑盒测试，也易于编写测试用的“桩”和“驱动”。 
“强内聚、松耦合”也是对组织结构的要求，项目组分为几个小组（正式的或非正式的），各小组的工作应是高度相关的，各小组之间的工作应尽量是较少相关或有 明确的接口，从而减少沟通成本。其实，“强内聚、松耦合”是系统中应遵守的普遍原则，我们在许多领域都可以找到它的应用。 
“强内聚、松耦合”是我们不得不念的“三字经”，我们一定要念好它。