在具有接口和专用代码的组件中组织SQL

我正在使用SQL Server 2008 R2中实现的许多逻辑重新编写一个应用程序。从逻辑上讲，业务逻辑可以划分为许多不同的组件

当前的实现是非常非结构化的：每个过程、函数、视图在任何地方访问和写入数据。我希望像对待JavaEE应用程序一样，将应用程序组织成更小的单元：带有公共接口的小罐子，但持久层和业务逻辑实现是隐藏的

除了prive接口表或存储过程之外，还有其他默认概念如何定义公共接口表或存储过程。在第一步中，使用命名约定可能就足够了。但是如果有更好的办法，请告诉我

---

[编辑]由于我们仅限于使用MS SQL Server：您如何看待在同一数据库中为每个模块定义单独方案的概念？

除了数据库表和过程的访问控制之外，没有其他真正的等价物，这与OO系统组织可见性的方式不同

---

最好的情况是将尽可能多的逻辑从存储过程转移到应用程序层，并处理其中的混乱。如果这是不可能发生的，我会考虑重构您的函数，使他们只执行单一的操作逻辑。如有必要，您可以将类似的存储过程分组到一个存储过程中，并让应用程序层仅通过这些功能进行操作。

我同意持久性层不应包含任何逻辑。在我们的特例中，DB不仅负责持久性，而且将来还将包含逻辑。这是我无法改变的。