我创建了一个简单的MVC Java应用程序，该应用程序通过数据表单将记录添加到数据库中。

我的应用程序收集数据，还对其进行验证和存储。这是因为数据是从其他用户在线获取的。数据本质上大部分是数字。

现在，在要存储到数据库（SQL Server）中的数字数据上，我希望我的应用执行计算并显示结果。用户对如何完成计算不感兴趣，因此必须将其封装。用户必须只能查看简单的计算数据（例如，A列数据减去B列数据除以C列数据）。我知道如何编写存储过程，但是我想要一个三层应用程序。

我希望通过对数据库进行计算来处理作为记录放入数据库中的数据。原始数据应保持不受影响，而新数据（计算后）必须作为新实体记录存储到数据库中。

我应该在哪里编写该后台计算代码？因为它是规则和业务逻辑，所以我应该将其放在新的JavaBeans文件中吗？

该业务逻辑应该被放置在模型中，我们应该瞄准肥胖模型和瘦控制器。

首先，我们应该从控制器逻辑开始。例如：在更新，你的控制器应引导你的代码的方法/服务是提供您更改模型。

在模型中，我们可以轻松创建帮助程序/服务类，在其中可以验证应用程序业务规则或计算。

概念总结

• 该控制器用于应用程序逻辑。该逻辑特定于您的应用程序希望如何与其所属的“知识领域”进行交互。

• 该模型用于独立于应用程序的逻辑。该逻辑在它所属的“知识领域”的所有可能应用中均应有效。

• 因此，将所有业务规则放在模型中是合乎逻辑的。

与往常一样，这取决于项目的复杂性。

在琐碎的应用程序中，领域模型的复杂性相对较小，您可以将逻辑放入模型中并每天称呼它。

但是，对于具有复杂模型和大量业务规则的非平凡应用程序，最好将它们分开一些。

如果将涉及多个模型的业务逻辑放入模型中，那么您将在这些模型之间引入紧密的耦合。随着应用程序的不断增长，这些模型会变得god models了解太多。这将很快变成一团糟，难以测试和维护。因此，在那种情况下，将逻辑放在单独的层中是有益的。

在决定抽象时，请始终考虑应用程序的复杂性和用途，并避免过度设计。对于琐碎的/小型的应用程序，引入比所需更多的层会增加而不是降低复杂度。

罗伯特·马丁（Robert叔叔）（鲍勃叔叔）在这个主题上有一篇不错的博客文章：清洁建筑。

将业务逻辑放入模型中可能听起来是最好的方法。控制器从远程Web应用程序接收呼叫。MVC Web服务上的控制器接受调用并将执行重定向到BL中的方法。现在，业务逻辑可以包含在“模型”中，但也可以放置在其他文件夹中，例如“业务逻辑”。因此，对于业务逻辑的去向没有严格的规定。

我一直在使用基于MVC 3.0构建的Web服务，而业务逻辑的容器是MVC MODEL。