比较器位于领域驱动的 MVC 世界中的什么位置?

发布于 2024-11-28 21:29:13 字数 918 浏览 1 评论 0原文

我有一个类需要以几种不同的方式进行排序,其中许多方式都违反了 equals() 约定,所以我需要有一堆不同的 Comparator类。我的问题是这些课程应该住在哪里?

因此,有一些具体的东西可以用作示例命名空间结构,并将问题限制为包结构而不是文件结构,让我们假设以下命名空间:

app
  domain
    exception
    hibernatemapping
  mvc
    propertyeditor
    tags
  persistence
    hibernate

域类位于 domain 命名空间中,以及相关的异常和 hibernate 映射文件分别位于 exceptionhibernatemapping 中。 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

慕烟庭风 2024-12-05 21:29:13

正如所建议的,像 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.

沧桑㈠ 2024-12-05 21:29:13

我制作了一个名为 comparators 的包,这是我存储我的包的地方。

I made a package called comparators which is where I store mine.

极度宠爱 2024-12-05 21:29:13

我通常采用以下结构:

company
  appname
     model
     util
     dao
     service
     controller

在这种类型的结构中,比较器可能会被转储到 util 包中(如果确实有很多比较器)。

然而,通常我发现比较器只在一个地方使用,所以我在实际使用的地方声明它们内联,例如

public class SomeService {
    public void someMethod(String id) {
        List<ListType> list = dao.getSomeListById(id);
        Collections.sort(list, new Comparator<ListType>() {
            public compare(ListType a, ListType b) {
            // ...
            }
        });
    }
}

I usually go with the following structure:

company
  appname
     model
     util
     dao
     service
     controller

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.

public class SomeService {
    public void someMethod(String id) {
        List<ListType> list = dao.getSomeListById(id);
        Collections.sort(list, new Comparator<ListType>() {
            public compare(ListType a, ListType b) {
            // ...
            }
        });
    }
}
记忆之渊 2024-12-05 21:29:13

我建议创建一个名为“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).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文