java web应用程序中的静态图层
我正在使用相当标准的Web /服务/数据访问分层设计构建趣味/学习的小型网站。java web应用程序中的静态图层
为了节省我不断创建我的服务层/数据访问层类的实例，我使它们中的方法都是静态的。我不应该因为它们使用局部变量等而导致并发性问题，也不会共享任何资源（目前情况很简单）。
据我所见，唯一的权衡就是我没有真正遵循一个真正的面向对象的方法，但是它又一次让代码更加干净。
是否有任何理由这不会是一种可行的方法？以后会出现什么样的问题？有一个“工厂”类能够根据需要返回我的服务和数据层类的实例会更好吗？
缺点：
- 您将无法编写单元测试，你将无法写模拟数据接入/业务逻辑对象要测试的。
- 因为不同的线程试图同时访问静态代码，所以会产生并发性问题 - 或者如果使用同步静态方法，则最终将使用线程排队等待使用静态方法。
- 您将无法使用实例变量，随着代码变得更加复杂，这将成为一种限制。
- 如果需要，将更难以替换业务或数据访问层的元素。
- 如果您打算以这种方式编写您的应用程序，那么最好使用专门用于这种方式的语言，如PHP。
你会被要么最好去非静态的业务/数据访问层类：
- 使用Singleton模式（创建每个类的一个实例和线程之间共享它们）。 ..
- 或者在需要的时候在每个线程中创建类的实例。
请记住，连接到您的应用程序的每个用户/会话都将在它自己的线程中运行 - 因此您的Web应用程序本质上是多线程的。
我认为你将有多个用户的所有静态方法的并发问题。 Web层将会发出并发用户。你所有的静态方法可以处理这个吗？也许，但他们不会一直被锁定在排队单个文件的请求？我不确定，从未尝试过你的想法。
你知道那些在游乐园的游乐设施，他们说“请随时保持你的手和脚在游乐场内”？事实证明，如果你不这样做，那么骑行会更有趣。唯一真正的折衷是你并没有真正遵循一种真正的保持你的手和脚的方式。
问题是，你应该遵循“真正的面向对象的方法”，就像有一个理由让你的手和脚保持在骑行中一样 - 在你到处开始出血的过程中，这很有趣。
您描述的方式，这本身不是“错误”的方法，但我真的没有看到你想要避免的问题。你不能在服务器启动时创建这些业务对象的单个实例，并根据需要将它们传递给你的servlet吗？
如果你准备把OO扔出窗口，你可能也想看看Singleton模式。
我真的没有看到你的设计的优势，并且有很多事情可能会出错。你正在保存一行代码，也许？这里有一些缺点的方法：
- 你不能轻易更换
- 你无法定义的实例变量，以方便分手逻辑分成多个方法
- 你的假设，你的业务逻辑的实现，多线程的问题不会出现几乎可以肯定是错误的
- 你不能轻易嘲笑他们进行测试
我真的没有看到一行代码的遗漏是BU你什么都没有。
这不是一个真正的“OO设计”问题，但更多的是合适的。你为什么以这样的程序方式使用Java？毫无疑问，PHP会更适合这种设计（并且通过不必编译和部署而实际节省您的时间）。
我只是让你的业务层非静态的;它会使维护，更改和演进应用程序变得更加容易。
您可能很难用这种类型的体系结构测试您的对象。例如，如果您有一层引用静态数据访问层的业务对象，则可能很难测试业务层，因为您无法轻松使用模拟数据访问对象。也就是说，在测试业务层时，您可能不希望在数据访问层使用“真实”方法，因为它们会对数据库进行不必要的更改。如果您的数据访问层不是静态的，您可以为业务层提供模拟数据访问对象用于测试目的。