比较器位于领域驱动的 MVC 世界中的什么位置?
我有一个类需要以几种不同的方式进行排序,其中许多方式都违反了 equals() 约定,所以我需要有一堆不同的 Comparator类。我的问题是这些课程应该住在哪里?
因此,有一些具体的东西可以用作示例命名空间结构,并将问题限制为包结构而不是文件结构,让我们假设以下命名空间:
app
domain
exception
hibernatemapping
mvc
propertyeditor
tags
persistence
hibernate
域类位于 domain
命名空间中,以及相关的异常和 hibernate 映射文件分别位于 exception
和 hibernatemapping
中。 persistence
拥有 DAO 接口,并在 hibernate
中实现基于 hibernate 的实现。所有 MVC 控制器都位于 mvc
中,在 propertyeditor
中具有专门的属性编辑器(这是 Spring MVC),并且在 tags
中支持自定义标记的类。
我的直觉告诉我,Comparator
应该位于 domain
命名空间下,也许位于 domain.comparator
中,但我不确定。
你会把它们放在哪里,为什么?
更新:许多人建议使用通用 Util
包。当走这条路线时,您会通过 UI 帮助程序与域帮助程序将 Util
类分开吗?例如,如果域需要出于业务逻辑原因对事物进行排序,但 UI 需要域不关心的其他排序?基本上,您是否倾向于每层都有一个辅助包?
I have a class that needs to be sortable in a couple of different ways, many of which break the equals()
contract, so I need to have a bunch of different Comparator
classes. The question I have is where should those classes live?
So that there is something concrete to use as an example namespace structure and to limit the question to package structure rather than file structure, lets assume the following namespaces:
app
domain
exception
hibernatemapping
mvc
propertyeditor
tags
persistence
hibernate
Domain classes live in the domain
namespace, and related exceptions and hibernate mapping files in exception
and hibernatemapping
respectively. persistence
holds DAO interfaces, with hibernate-based implementations in hibernate
. All of the MVC controllers live in mvc
, with specialized property editors (this is Spring MVC) in propertyeditor
and classes that back custom tags in tags
.
My gut says that Comparators
should live under the domain
namespace, perhaps in domain.comparator
, but I'm not sure.
Where would you put them and why?
Update: A number of people have suggested using a general Util
package. When going that route, would you separate out the Util
classes by UI helpers vs. domain helpers? For example, if the domain needed to sort things for business logic reasons, but the UI needed additional sortings that the domain doesn't care about? Basically, would you tend to have a helper package per-layer?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
正如所建议的,像 util 或 commons 包之类的东西似乎是最有意义的,但如果您不知道在哪里放置某些东西,请确保您最终不会将其用作“goto”包。
我还建议查看按功能包。因此,您的比较器将仅使用其所使用的任何相应功能。再次强调,这只是一个建议 - 您必须为项目选择最佳布局。
As suggested, something like a util or a commons package would seem to make the most sense, though be sure you don't end up using that as a "goto" package if you don't know where to put something.
I'd also suggest looking into package by feature. In this cause, your compartor would just go with whatever corresponding feature its used with. Again, this is only a suggestion - you'll have to make the call for the best layout of your project.
我制作了一个名为
comparators
的包,这是我存储我的包的地方。I made a package called
comparators
which is where I store mine.我通常采用以下结构:
在这种类型的结构中,比较器可能会被转储到 util 包中(如果确实有很多比较器)。
然而,通常我发现比较器只在一个地方使用,所以我在实际使用的地方声明它们内联,例如
I usually go with the following structure:
In this type of structure a comparator would probably get dumped into the util package (if there were really a lot of comparators).
However, usually I find that comparators are used in exactly one place, and so I declare them inline where they're actually used, e.g.
我建议创建一个名为“app.util”或“app.helper”的包。
从概念上讲,在领域驱动设计中,这属于基础设施层(http://www.infoq .com/articles/ddd-in-practice)。
I suggest to create a package called "app.util" or "app.helper".
Conceptionally speaking, in Domain Driven Design this belongs in the infrastructure layer (http://www.infoq.com/articles/ddd-in-practice).