我正在修改一个在 SQL (MS SQL Server 2008 R2) 中实现了很多逻辑的应用程序。从逻辑上讲，业务逻辑可以拆分为许多不同的组件。
当前的实现非常非结构化：每个过程、函数、视图在任何地方访问和写入数据。我想将应用程序组织成更小的单元，就像使用 JavaEE 应用程序一样：具有公共接口的小型 JAR，但隐藏了持久层和业务逻辑实现。
除了“私有接口表或存储过程”之外，是否有任何默认概念如何定义“公共接口表或存储过程”。在第一步中，使用命名约定可能就足够了。但如果有更好的方法，请告诉我。
[编辑] 由于我们仅限于使用 MS SQL Server：您如何看待在同一数据库中为每个模块定义单独方案的概念？
There's no real equivalent to this other than access control of the database tables and procedures, which is different from how a OO system organizes visibility.
The best case scenario would be to move as much logic from the sprocs into the application layer and deal with the messiness there. If this isn't likely to happen, I would consider refactoring your functions so that they perform only single operations (logically). If necessary, you could group similar sprocs under a single one and have the application layer operate only through those functions.