我想要技术专家的意见，
我们正在使用 Oracle 8i 数据库迁移以 Oracle 形式构建的遗留系统。客户想在 Web 应用程序中重新开发这个遗留系统，所以我们选择 MVC3 框架。客户希望我们重用遗留系统的所有存储过程，其中包含应用程序的业务逻辑。
如果每个业务逻辑都是用存储过程编写的，那么我认为我们的系统中不需要业务层。
所以我创建了三层-：
接口层 -> MVC 3 应用程序
数据层 -> 用于从存储过程中获取信息
DTO 层 -> 用于将数据从接口层传输到数据层。
我没有创建业务对象或业务层，因为所有业务逻辑都在存储过程中。我不喜欢创建只将请求从接口层转发到数据层并且没有任何业务层的业务层。
这种方法是否正确？
我建议您仍然创建一个业务层，即使它只是将所有操作转发到作为数据层一部分的存储过程。
由于客户希望您重用其中包含业务逻辑的所有存储过程，因此他不希望您修改或添加更多存储过程听起来也很合理。可能会发生需要您以不同方式实现它们或更改业务逻辑顺序的事件，然后您可以将其放入业务层。也许您可能需要一个不以数据为中心的业务逻辑——这意味着将它放在存储过程中听起来并不合理，例如发送电子邮件或与第三方系统协调。
业务层是单独的项目
如果业务层是一个单独的项目，我会专注于项目的一部分。在服务器端应用程序中拥有一个具有最少业务逻辑（通常是验证逻辑）的接口层是完全合理的。您可能希望客户端中的业务逻辑最少，以使其更具响应性，即它不会一直返回数据库来验证输入。
您可以在数据库中拥有业务层（不是我会做这样的事情），或者在服务器端 Java 中，或者在客户端中的一些（不是我建议在很大程度上这样做）