MVC设计混乱
我现在正在开发一个小型预订网站。该站点有一个 servlet，带有一个大的 if-else 块，其中包含大约 85 个条件，用于将请求重定向到适当的 jsp。同一个servlet 包含一些业务逻辑。该servlet 直接调用数据访问对象。这些数据访问对象也有一些业务逻辑。因此业务逻辑在 servlet 和 DAO 之间共享。我有两个困惑。
1) Servlet 是一种反模式。所以我试图让它更小，并将其划分为多个 servlet，以便每个 servlet 都有某种特定的用途。我的问题是我应该为每种条件制作一个 servlet 吗？这将产生 85 个不同的 servlet。
2) DAO 和 servlet 之间应该有多少层。我正在考虑两个，因为我需要一层将特定于 Web 前端的输入转换为通用请求。第二层将处理通用请求并在需要时调用 DAO。因此，如果稍后我们决定制作移动应用程序。我们只需要对移动前端特定的请求进行一层处理，并将其转换为通用请求。但这会导致重复代码。我对一层和两层有点困惑。
我知道这是一个需要阅读的大问题。但感谢您的时间和提前回复。
I am working on a small booking site right now. And that site has one single servlet with a big if-else block with around 85 conditions to redirect the request to the appropriate jsp. The same servlet contains some business logic. This servlet directly calls the data access objects. Those data access objects also have some business logic. So the business logic is shared between the servlet and the DAOs. I have two confusions.
1) The servlet is an anti-pattern. So I am trying to make it smaller and divide it into multiple servlets so that each servlet have some kind of specific purpose. My question is should I make one servlet for each conditions. That would make 85 different servlets.
2) How many layers should I have between the DAO and the servlets. I am thinking two because I need to one layer would convert the input specific to the web front end to a generalized request. And the second layer would process the generalized request and call the DAO's when required. So that if later on when we decide to make a mobile app. We just need to make one layer of processing of request specific to the mobile front and and convert it to a generalized request. But this is leading to repeated code. I am a little confused between one layer and two layers.
I know its a big question to read. But thanks for your time and replies in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果存在目的或作用相似的操作/条件，则可以将它们组合到具有多个处理程序方法的类中。例如，所有作用于用户的 servlet 都可以组合成一个类。这是否有意义取决于我们没有的信息。
您应该有多少层？不知道。一般来说，至少有一个，服务层。服务将 DAO 功能聚合到事务单元中。条件处理程序管理 Web 层和业务层之间的接口。
看起来你确实是在完全重新发明一个已经被发明了很多次的轮子。考虑使用现有框架，或简化现有代码：不要使用多个 servlet 来处理条件，而是尽可能从 servlet 规范中分派到命令处理程序。
如果你的目标是极度简单，像 Bear's Front Man 这样的东西是一个薄而可爱的层这消除了很多复杂性和噪音。像 Guice Servlet 这样的东西允许依赖注入，而无需成熟的 Spring/etc 。堆。
处理特定 URL 的类（或“命令”——请参阅任何命令模式文档）不会不需要是实际的 servlet；它们可以是通用类。
它们可能是servlet——但是与servlet规范的耦合越松，测试和扩展就越容易。
从 URL 获取“命令”可以像在映射中查找命令、实例化适当的类、传递各种工件（例如请求和会话参数）以及调用实现中的方法一样简单。从某种意义上说，每个框架最终都会在某种程度上像这样工作。
If there are actions/conditions that are similar in purpose or in what they act upon, they can be combined into classes that have multiple handler methods. For example, all servlets that act on users could be combined into a single class. Whether or not that makes sense depends on information we don't have.
How many layers should you have? Don't know. In general there is at least one, a service layer. Services aggregate DAO functionality into transactional units. The condition handlers manage the interface between web and business layers.
It sure looks like you're completely re-inventing a wheel which has been invented many times already. Consider either using an existing framework, or streamlining your existing code: instead of making multiple servlets to handle the conditions, dispatch to a command handler as de-coupled from the servlet spec as possible.
If you're aiming for drop-dead simplicity, something like Bear's Front Man is a thin, cute layer that does away with a lot of complexity and noise. Something like Guice Servlets allows dependency injection without a full-blown Spring/etc. stack.
Classes that handle a specific URL (or "command"--see any command pattern documentation) don't need to be actual servlets; they can be generic classes.
They may be servlets--but the looser the coupling to the servlet specification you have, the easier things are to test and extend.
Getting from a URL to a "command" can be as simple as looking up a command in a map, instantiating the appropriate class, passing along various artifacts (e.g., request and session parameters), and calling a method in the implementation. In a sense, every framework ends up working like this on some level.
这只是一种意见，但是：
It's just an opinion, but: