在一个独立的应用程序'.,业务逻辑必须驻留在哪里?

RKh*_*RKh 1 database sql-server oracle

我读了Tom Kyte的"设计有效的Oracle".在那里,他说要在DB本身编写大部分代码来减少应用程序代码.它在分布式环境中很好,但它在独立应用程序中也有优势吗?

我的应用.在.NET中.

Ton*_*ews 6

是的,即使对于独立应用程序,将业务逻辑放在Oracle数据库中也有很多优点:

  • 性能和可伸缩性,业务逻辑涉及访问或更新数据库
  • 依赖关系跟踪:可以轻松找到对代码中的表和其他对象的引用
  • PL/SQL是设计用于编写访问数据库,很简单,并且不需要建立大量的动态SQL制备的报表,或使用混淆层像Hibernate这样做对你的代码.

我实际上会偷走Josh的一些答案并将其转动180度:

如果您的数据库只支持单个应用程序,并且您从未期望相同的数据具有不同的用例,具体取决于谁使用它...那么确保将业务逻辑放在...

应用.

我的意思是,您是否真的希望两个不同的应用程序访问相同的数据行,但对该数据的更改应用不同的规则?如果只是通过使用不同的访问路径来破解它,那么拥有"规则"有什么意义?

请注意,我省略了Josh答案的这一部分:

...如果您从未计划使用其他存储机制......

当然,如果您计划支持多个数据库,或者丢弃Oracle并开始使用SQL Server或其他完全来存储数据,那么您将不希望使用PL/SQL来编写代码.但是在许多情况下,许多情况都不会发生,而且为了自己的利益而建立数据库独立性是不明智的.

  • @Tony:显然我们在这方面存在语言差异,但我几乎从未在一个数据库上工作,**数据库不被多个应用程序访问.每个人都需要自己的一套业务规则.最后,需要仔细规划以确保不会将应用程序逻辑泄露到数据库中.有些规则在数据库级别实施更有意义,但只适用于那些适用于数据完整性的规则.应用程序逻辑应该保留在它所属的位置. (2认同)
  • @Josh,我也没有(在多个应用程序无法访问的数据库上工作).但是(也许这与Oracle而不是其他DBMS不同)并不是问题:如果需要,每个应用程序都可以在数据库上拥有自己的业务逻辑包"模式",从而访问数据的中心模式.因此,您可能拥有一个包含HR应用程序的HR数据库,以及一个访问HR数据库以获取信息的项目跟踪系统,两者都有一些实现其特定业务规则的包.你得到了你想要的所有关注点! (2认同)