网络应用架构
我目前正在使用两个实体：
- 一个使用 jQuery 的 JSP
- 一个 RESTful WebService，我用它在数据库中查询 Foo 对象的集合。
在 JSP 中，我对返回集合的 WS 进行 AJAX 调用，然后开始迭代它，目的是在数据表中显示每个 Foo 的一些变量。有一个业务需求，如果 Foo.bar 存在，则将其显示在屏幕上。否则，在栏列中显示 Foo.baz 的值。根据我的定义，这是特定于应用程序的业务逻辑。
我的问题是：这个逻辑应该去哪里？我不认为它属于 WS，因为我希望我自己和其他人依靠它作为获取原始 Foo 对象的一站式商店，而不是已应用上述条件的 Foo 对象。我也不认为它属于JSP，因为它应该只是显示数据的一种方式。我缺少什么？
I'm currently working with two entities:
- A JSP that uses jQuery
- A RESTful WebService that I use to query a database for a collection of Foo objects.
In the JSP, I make an AJAX call the WS that returns my collection, and I begin to iterate through it, with the intent of displaying some of each Foo's variables in a data table. There's a business requirement that says, if Foo.bar is present, show it on the screen. Otherwise, in the bar column, show the value of Foo.baz. This, by my definition, is application-specific business logic.
My question: where should this logic go? I don't think it belongs in the WS, because I want myself and others to rely on this as your one-stop shop for getting raw Foo objects, not Foo objects that have had the above conditions applied to them. I also don't think it belongs in the JSP, because it should only be a means by which to display data. What am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你自己也说了：
这听起来非常像显示逻辑，所以我认为 JSP 是一个合适的位置，因为它处理应用程序的该层。
You said it yourself:
That sounds an awful lot like display logic, so I think the JSP is an appropriate place since it handles that layer of the application.