Best practise : 封装存储过程

 

如果我们写了一个存储过程，比如叫做delete_dept,功能非常简单——就是删除指定id的部门：

 

CREATE PROCEDURE [dbo].[delete_dept]        

  @id int

AS

delete  from dept where id=@id

RETURN 0

 

那么这样的存储过程，我们应该在代码中如何调用呢？

现在的大部分做法都是采用一个封装的函数，传递存储过程名称、参数为函数的参数。还是以这个存储过程为例，假设方面名称为RunProc,那么调用的方法就是：

  RunProc("delete_dept",1);

这是最简单的，也是最容易想到的做法。为了方便我们给它取个名字：RunProc方法，可是直观的做法，不一定适合大型的产品工程。在客户端代码中，如果能够这样做，是不是更好：

  delete_dept(1);

为了方便，也给它取个名字：LocalFunction方法。为此我们只需要实现一个函数就行了：

void delete_dept(int id)

{

  RunProc("delete_dept",id); 

}

尽管代码是等效的，代码的可读性也差不多，但是从架构角度看，后者要比前者要好，因为后者改善了不同层次代码的耦合关系。既然谈到了关系，我们用图的方式来看更好。看看数据库层和应用层的耦合关系的对比：

 

可是连接不仅仅没有减少，反而多了一个啊？也许你要提出这样的疑问。这里最重要的点在于，层之间的耦合减少了。从原来的3个到现在的1个。层之内的联系可以多，这就叫做内聚,层之间的调用要少，这就叫做低耦合。这是高内聚低耦合的一个基本原则。尽管客户代码层之间的耦合多了，但是可以充分利用类的封装、继承、多态等特性，从而让代码更清晰。我们来看看好处：

a.          Sql和c#是不同类型的，本来应该有隔离层

b.          让存储过程和函数调用一致，从而对客户端代码更加友好

c.           同类的存储过程封装函数都可以放到一个类内，做好归类工作

d.          调用都会转成强类型

不仅如此，更加重要的是，这样做了后，对变化的适应能力更强,这个内容下一篇再讲。待续。