为了使代码更易于维护(即更容易更改业务规则而不重新编译代码),在存储过程中放置代码的理由是什么？
所有其他条件相同的是什么使存储过程更好/更差的维护？
出于多种原因,存储过程是一种不好的做法.
最重要的一个是关注点的分离.使用存储过程,您可以在数据层中使用业务逻辑,而不是在其所属的服务层中.这样做的一个结果是,您现在只能使用一种语言和一种语言来实现业务逻辑.随着新技术的出现,您没有良好的迁移路径.
避免存储过程的另一个可靠原因是存储过程在您和数据库供应商之间建立了牢固的联系.将更改为不同的数据库供应商将非常困难,而在服务层中拥有业务逻辑将允许您非常轻松地交换数据库.因此,存储过程为数据库供应商提供了很大的好处,而不是为您提供.
接下来,可扩展性.在中间层创建服务并在集群中分发服务非常简单.你打算用存储过程怎么做？我认为将存储过程集中在甚至八台机器上是非常困难的.
接下来,与其他系统集成.如果您的系统从数据库中提取数据,依赖存储过程以及来自其他系统的其他数据,那么该逻辑几乎肯定必须位于服务层中.如果您的某些业务逻辑位于服务层中,而某些业务逻辑位于业务层中,那么您将面临一些维护麻烦.
这可能取决于您的系统.对我们来说,Stored Procs几乎全部使用.我们只有一个网站,因此在存储过程中使用SQL语句会使我们的DBA更容易调整查询并重新创建导致问题的性能.
想想替代方案......
将查询硬编码到您的系统中
根据用户输入构建查询字符串
让您的代码根据您的业务实体和数据库命名约定动态生成查询(通过ORM,LINQ,CodeDom等...)
等等...
然后考虑您的要求和环境......
您的开发人员是否熟悉您的数据库管理工具,或者您是否有更多的数据库程序员和管理员处理当时的数据库端？
您是否需要频繁更改数据库模式？
安全性怎么样？您是否一直需要安全性到数据库用户级别？在代码或数据库中管理安全性会更容易吗？
您的开发人员是否可以通过ORM提高工作效率,而不必为自己编写DAL,或者您是否希望以自定义方式向DAL添加ORM无法提供的复杂性？
等等...
根据他们工作的系统和环境可能与您自己的系统和环境大不相同,人们会对procs是否更容易维护有不同的看法.您应该做的不仅仅是想知道它们是否更容易维护,而是要弄清楚它们是否满足您的需求.这是一个非常好的问题,但也许可以编辑你的帖子并解释一下你的环境.你可能会得到更有针对性的建议.
存储过程提供了许多优于在应用程序中保留查询的优点,并且已经提到了许多优点.
存储过程充当应用程序和数据之间的抽象层,抽象层很少是坏事.
如果您具有级联数据库操作,则可以实现一定程度的重用.该Delete_Employee过程中,例如,可以调用Delete_Address过程中的事务,做很多其他的事情,从应用程序的单个数据库请求.
存储过程下面的一层视图可用于将应用程序与架构更改和查询/连接性能调整隔离开来.
存储过程层是可靠的企业体系结构和框架的重要组成部分.这些存储过程应该不包含业务逻辑,当然,它们只应传递数据而不是操纵它.
为了实现这些好处,良好的规则是为了在应用程序中的所有过程中保持一致性和相同的粒度.我已经使用了许多100个程序来处理应用程序.如果所有这些查询都在代码中,那么实现数据级安全性将会更加困难,甚至是不可能的.存储过程可以很容易地生成.我觉得存储过程的总体生产率高于没有存储过程.当然,存储过程可以广告应该在源代码控制中,就像所有其他数据库对象一样.
如果您的基础软件部署在多个不同的客户站点,则可以通过数据库(视图和存储过程)完成每个客户所需的大部分定制.您几乎可以将SP视为一个接口,来回传递标准数据,而不用担心内部发生的事情.
当然,这也可以通过其他方式处理,例如每个安装的自定义.dll数据层.
但在某些情况下,SP中的自定义而不是.dll允许更快的自定义,并允许DBA或数据专家接管,让程序员继续编码.
请记住,SP中的代码可供更多人(在本例中为客户)使用,而不是编译代码.根据您的情况,这可能是好的也可能是坏的.
在某些企业中,更改存储过程在政治上比重新安装软件更容易(这更多地取决于谁有更严格的规则,开发人员和项目经理,DBA或IT /帮助台).
京公网安备 11010802040832号 | 京ICP备19059560号-6 