Java Web 应用程序中的静态层
我正在使用相当标准的 Web/服务/数据访问分层设计构建一个用于娱乐/学习的小型网站。
为了使我不必不断创建服务层/数据访问层类的实例，我将它们中的方法全部设为静态。 我不应该遇到并发问题，因为它们使用局部变量等并且不共享任何资源（目前事情很简单）。
据我所知，唯一的权衡是我并没有真正遵循真正的面向对象方法，但它又使代码更加简洁。
有什么理由认为这不是一个可行的方法吗？ 以后可能会出现什么样的问题？ 拥有一个可以根据需要返回服务和数据层类的实例的“工厂”类会更好吗？
I am building a small website for fun/learning using a fairly standard Web/Service/Data Access layered design.
To save me from constantly having to create instances of my service layer/data access layer classes, I have made the methods in them all static. I shouldn't get concurrency issues as they use local variables etc and do not share any resources (things are simple enough for this at the moment).
As far as I can see the only trade-off for this is that I am not really following a true OO approach, but then again it keeps the code much cleaner.
Is there any reason this would not be a viable approach? What sort of problems might arise later on? Would it be better to have a "factory" class that can return me instances of the service and data layer classes as needed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
按照您描述的方式，这本身并不是“错误”的方法，但我并没有真正看到您试图避免的问题。 难道您不能在服务器启动时创建这些业务对象的单个实例并根据需要将它们传递给您的 servlet 吗？
如果您准备好将面向对象扔出窗外，您可能还想看看单例模式。
The way you describe it, this isn't the "wrong" approach per se but I don't really see the problem you're trying to avoid. Can't you just create a single instance of these business objects when the server starts up and pass them to your servlets as needed?
If you're ready to throw OO out the window you might want to check out the Singleton pattern as well.
缺点：
您最好通过以下任一方式选择非静态业务/数据访问层类：
请记住，连接到您的应用程序的每个用户/会话都将在其自己的线程中运行 - 因此您的 Web 应用程序本质上是多线程的。
Disadvantages:
You would be better off going for non-static business/data access layer classes by either:
Keep in mind that each user/session connected to your application will be running in it's own thread - so your web application is inherently multi-threaded.
您知道游乐园里的那些游乐设施上写着“请始终将手脚放在游乐设施内”吗？ 事实证明，如果您不这样做，骑行会更有趣。 唯一真正的权衡是，您并没有真正遵循真正的始终将手脚放在骑行内的方法。
重点是——你应该遵循“真正的面向对象方法”，就像你有理由让你的手和脚留在骑行中一样——这很有趣，直到你开始到处流血。
You know those rides at the amusement park where they say "please keep your hands and feet inside the ride at all times"? It turns out the ride is a lot more fun if you don't. The only real trade-off is that you're not really following a true keeping-your-hands-and-feet-inside-the-ride-at-all-times approach.
The point is this -- there is a reason you should follow a "true OO approach", just as there's a reason to keep your hands and feet inside the ride -- it's great fun until you start bleeding everywhere.
我认为您会遇到多个用户的所有静态方法的并发问题。 Web 层将排除并发用户。 你所有的静态方法都能处理这个问题吗？ 也许吧，但是它们不会一直被锁定在单个文件中对请求进行排队吗？ 我不确定，从未尝试过你的想法。
I would think that you will have concurrency issues with all static methods with multiple users. The web layer will thread out concurrent users. Can all your static methods handle this? Perhaps, but won't they constantly be locked in queuing the requests in single file? I'm not sure, never tried your idea.
使用这种类型的架构对对象进行单元测试可能会遇到困难。 例如，如果您有一个引用静态数据访问层的业务对象层，则测试业务层可能会很困难，因为您无法轻松使用模拟数据访问对象。 也就是说，在测试业务层时，您可能不想在数据访问层中使用“真正的”方法，因为它们会对数据库进行不必要的更改。 如果您的数据访问层不是静态的，您可以向业务层提供模拟数据访问对象以用于测试目的。
You may have difficulty unit-testing your objects with this type of architecture. For example, if you have a layer of business objects that reference your static data access layer, it could be difficult to test the business layer because you won't be able to easily use mock data access objects. That is, when testing your business layer, you probably won't want to use the "real" methods in the data access layer because they will make unwanted changes to your database. If your data access layer was not static, you could provide mock data access objects to your business layer for testing purposes.
我并没有真正看到你的设计的优势，而且有很多事情可能会出错。 也许您正在保存一行代码？ 您的方法有一些缺点：
我真的不认为省略一行代码会给你带来任何好处。
这并不是一个真正的“OO 设计”问题，而更多的是一个适当性的问题。 为什么你还要以这种程序化的方式使用 Java？ 当然，PHP 更适合这种设计（并且实际上无需编译和部署，从而节省了您的时间）。
我只会让你的业务层成为非静态的； 它将使维护、更改和发展您的应用程序变得更加容易。
I don't really see the advantage to your design, and there are many things that could go wrong. You are saving a line of code, maybe? Here's some disadvantages to your approach:
I really don't see that the omission of one line of code is buying you anything.
It's not really an "OO Design" issue, but more of an appropriateness. Why are you even using Java in such a procedural way? Surely PHP would be more appropriate to this kind of design (and actually save you time by not having to compile and deploy).
I would just make your business layer non-static; it will make it so much easier for to maintain, change, and evolve your application.