我正在使用相当标准的Web /服务/数据访问分层设计构建一个用于娱乐/学习的小型网站。

为了使我免于经常创建服务层/数据访问层类的实例的麻烦，我将它们中的方法全部设为静态。我不应该遇到并发问题，因为它们使用局部变量等并且不共享任何资源(此刻事情已经足够简单了)。

据我所知，唯一的权衡是我并没有真正遵循真正的面向对象方法，但是这样做又使代码更加整洁。

是否有任何理由认为这不是可行的方法？以后可能会出现什么样的问题？最好有一个"工厂"类，可以根据需要向我返回服务和数据层类的实例？

解决方案

我认为我们将在具有多个用户的所有静态方法中遇到并发问题。 Web层将淘汰并发用户。我们所有的静态方法都可以处理吗？也许吧，但是他们不会一直被锁定在单个文件中对请求进行排队吗？我不确定，从未尝试过想法。

我们知道游乐园里的游乐设施会说"请始终将手和脚放在游乐设施内"吗？事实证明，如果我们不喜欢，这次旅程会有趣得多。唯一真正的权衡是，我们并没有真正遵循始终将自己的手脚放在骑乘方法中。

关键是-有一个理由应该遵循"真正的面向对象方法"，就像有理由将手和脚放在车内一样-这很有趣，直到我们到处流血为止。

按照描述方式，这本身并不是"错误"的方法，但是我没有真正看到我们要避免的问题。我们不能在服务器启动时仅创建这些业务对象的单个实例，然后根据需要将它们传递给servlet吗？

如果我们准备将OO扔出窗口，则可能还需要签出Singleton模式。

我看不出设计有什么优势，而且有很多地方可能会出错。我们正在保存一行代码，也许吗？这是方法的一些缺点：

• 我们无法轻松替换业务逻辑的实现
• 我们不能定义实例变量来促进将逻辑分解为多个方法
• 我们认为不会出现多线程问题的假设几乎可以肯定是错误的
• 我们不能轻易地嘲笑它们进行测试

我真的没有看到遗漏任何一行代码就能买到任何东西。

这实际上不是一个" OO设计"问题，而是更多的适当性。我们为什么还要以这种过程方式使用Java？当然，PHP更适合这种设计(并且无需编译和部署，实际上可以节省时间)。

我只是将业务层设为非静态；它将使维护，更改和发展应用程序变得非常容易。

使用这种类型的体系结构，可能很难对对象进行单元测试。例如，如果我们有一个引用静态数据访问层的业务对象层，则可能很难测试业务层，因为我们将无法轻松使用模拟数据访问对象。也就是说，在测试业务层时，我们可能不希望在数据访问层中使用"真实"方法，因为它们会对数据库进行不必要的更改。如果数据访问层不是静态的，则可以向业务层提供模拟数据访问对象以进行测试。

缺点：

• 我们将无法编写单元测试，因为我们将无法编写要测试的模拟数据访问/业务逻辑对象。
• 当不同的线程尝试同时访问静态代码时，我们将遇到并发问题；或者，如果我们使用同步的静态方法，最终将导致线程排队使用这些静态方法。
• 我们将无法使用实例变量，随着代码变得更加复杂，实例变量将成为限制。
• 如果需要，将更难以替换业务或者数据访问层的元素。
• 如果打算以这种方式编写应用程序，则最好使用旨在以这种方式工作的语言，例如PHP。

我们最好通过以下两种方式选择非静态业务/数据访问层类：

• 使用单例模式(创建每个类的单个实例并在线程之间共享它们)...
• 或者在需要时在每个线程中创建类的实例。

请记住，连接到应用程序的每个用户/会话都将在其自己的线程中运行，因此Web应用程序本质上是多线程的。