我现在在一个小型预订网站上工作。并且该站点有一个单独的servlet，带有一个大的if-else块，大约有85个条件将请求重定向到适当的jsp。同一个servlet包含一些业务逻辑。该servlet直接调用数据访问对象。这些数据访问对象也有一些业务逻辑。因此，业务逻辑在servlet和DAO之间共享。我有两个困惑。
1）servlet是一种反模式。因此，我试图将其缩小并将其划分为多个servlet，以便每个servlet都具有某种特定的用途。我的问题是我应该为每个条件制作一个servlet。那会产生85个不同的servlet。
2）DAO和servlet之间应该有多少层。我在考虑两个，因为我需要一个层将特定于Web前端的输入转换为通用请求。第二层将处理通用请求并在需要时调用DAO。因此，如果我们决定制作移动应用程序的话。我们只需要对移动前端进行一层特定的请求处理，然后将其转换为通用请求。但这导致重复的代码。我在一层和两层之间有点困惑。
我知道这是一个很重要的问题。但感谢您的时间和提前回复。
答案 0 :(得分：1)
如果存在目的相似的行为/条件或它们的行为，它们可以组合成具有多个处理程序方法的类。例如，作用于用户的所有servlet可以组合成一个类。这是否有意义取决于我们没有的信息。
应该多少层？不知道。通常，至少有一个服务层。服务将DAO功能聚合到事务单元中。条件处理程序管理Web层和业务层之间的接口。
看起来你确实已经完全重新发明了已经多次发明过的车轮。考虑使用现有框架或简化现有代码：而不是使多个servlet处理条件，尽可能从servlet规范中解析为命令处理程序。
如果你的目标是昙花一现，像Bear's Front Man这样的东西是一层薄而可爱的层，可以消除很多复杂性和噪音。像Guice Servlets之类的东西允许依赖注入而没有完整的Spring / etc。叠加。
处理特定URL（或“命令” - 请参阅任何command pattern文档）的类不需要是实际的servlet;它们可以是通用类。
他们可能是servlet - 但是与你拥有的servlet规范的耦合越松散，就越容易测试和扩展。
从URL获取“命令”可以像在地图中查找命令，实例化相应的类，传递各种工件（例如，请求和会话参数）以及在实现中调用方法一样简单。从某种意义上说，每个框架最终都会在某种程度上像这样工作。
答案 1 :(得分：0)
这只是一个意见，但是：