网站类图中的视图和 Servlet？
我即将开发这个小网站，它基本上是一个简单的网络应用程序，用于为医生存储有关患者的信息。 我收到任务的公司要求提供带有类图的介绍，老实说，我已经这样做了，但仅限于独立应用程序，我在设计网站类图方面非常新。 我使用的是 Ivar Jacobson 的用例迭代方法，其中用例包括： 参与者、场景（表示一切顺利时的用户系统交互）和最坏的情况场景（出现问题时的解决方案）。 通过应用这个，我得出了一个很好的结论，一个精心准备的类图。 我的问题是我怀疑是否应该在图中包含jsp视图和servlet（在我的例子中是动作bean，因为我使用Stripes），我的意思是，业务类和用户之间的桥梁是jsp-视图和提供的信息将由 servlet（或操作 bean）处理，您会将它们包含在类图中吗？ 对于小型项目来说，这可能不太相关，但如果您的项目有 30 个视图和 20 个 servlet，那么图表会变得混乱且巨大。 你对此有什么建议吗？
谢谢
I'm about to develop this small website, its basically a simple web app to store informations about patients for a doctor.
The company i have got the assignment from demands an introducton with a class diagram, honstly, i have done this already but only for standalone apps, i'm very new in designing class diagrams for websites.
What i'm using is the Ivar Jacobson's iterative metho with usecases, where a usecase includes:
Actors, scenario (representing user-system interactions when all goes fine), and worse case scenatio (solutions when something goes wrong).
By applying this i came to a good conclusion, a well prepared class diagram.
My problem is that i'm doubting whether or not i should include jsp views and servlets(in my case action beans since i use Stripes) in the diagram, i mean, the bridge between the business-classes and the user are the jsp-views and the provided info are going to be processed by the servlets (or action beans), would you include them in the class diagram?
For a small project tis might be not that relevant but what if you have a project with 30 views and 20 servlets, the diagram would become messy and huge.
Do you have some tips about it?
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您需要类图的唯一原因是为了满足客户，那么最好首先找出他们正在寻找什么。
然而，如果它们不具体（并忽略愤世嫉俗的选项），我建议如下：
理由：领域模型非常适合检查范围和验证领域规则（关系）。 “设计”类图只会混淆这一点。 jsp、控制器等的激增隐藏了底层架构模式，同时分散了人们对领域模型中有用内容的注意力。
嗯。
If the only reason you need the class diagram is to satisfy the client, best find out what they're looking for first.
If however they're not specific (and ignoring the cynical options) I'd suggest the following:
Rationale: a domain model is good for checking scope and verifying domain rules (relationships). A "design" class diagram only obfuscates that. A proliferation of jsps, controllers, etc. hides the underlying architecture pattern while distracting from the useful stuff in the domain model.
hth.