afBedSheet是将类标记为服务，将方法作为路由处理程序来提供方面吗？

Question

我正在使用扇汤姆的afBedSheet框架，在它的这里的文件中，示例是.

using afIoc
using afBedSheet

class HelloPage {
  Text hello(Str name, Int iq := 666) {
    return Text.fromPlain("Hello! I'm $name and I have an IQ of $iq!")
  }
}

class AppModule {
  @Contribute { serviceType=Routes# }
  static Void contributeRoutes(OrderedConfig conf) {
    conf.add(Route(`/index`, Text.fromPlain("Welcome to BedSheet!")))
    conf.add(Route(`/hello/**`, HelloPage#hello))
  }
}
...

当添加越来越多的路由时，上面的contributeRoutes方法开始变得难以读取和维护，特别是当路由处理程序来自不同的类时。

我的做法不同:在每个Service类上，我添加了一个静态方法，该方法返回由其方法处理的路由列表，如本例所示：

using afBedSheet

class Info {

    static Route[] routes() {[
        Route(`/info`, #all),
        Route(`/info/pod`, #podAll),
        Route(`/info/pod/name`, #podName),
        Route(`/info/pod/version`, #podVersion),
    ]}

    Text all() {
        Text.fromJson(["This application blah blah blah"])
    }

    Text podAll() {
        pod := Pod.of(this)
        return Text.fromPlain("$pod.name $pod.version.toStr")
    }

    Text podName() {
        Text.fromPlain(Pod.of(this).name)
    }

    Text podVersion() {
        Text.fromPlain(Pod.of(this).version.toStr)
    }

}

那么我的AppModule就像这样

using afIoc
using afBedSheet

class AppModule {

    @Contribute { serviceType=Routes# }
    static Void contributeRoutes(OrderedConfig conf) {
        Info.routes.each { conf.add(it) }
        AnotherService.routes.each { conf.add(it) }
        YetAnotherService.routes.each { conf.add(it) }
        ...
}

我试图保持AppModule干净，以及更接近于实现类的路由定义和处理程序映射。我希望这将使服务/路由更易于维护，但我不确定这是一个好主意还是坏主意。我发现这样做的好处是

• 如果将路由处理程序方法添加到类中，则在同一类上声明路由
• 因为路由处理程序方法是同一个类的一部分，所以我只需键入槽名(例如#podVersion而不是Info#podVersion)，这在我看来更容易阅读。

但是，正如我所说的，我只是在玩afBedSheet，我想从一个用这个框架做了一个真正的生产项目的人那里知道，是否有一个很好的理由来声明AppModule类中的路由，如示例所示。

此外，如果我正在做的事情是好的还是好的，我想知道是否有(或者说添加一个好主意)将我上面的Info类更改为更类似的东西：

using afBedSheet

@Service // Assuming there is such facet to let afBedSheet discover services
class Info {

    @Route { `/info` }  // <- Route handler facet
    Text all() {
        Text.fromJson(["This application blah blah blah"])
    }

    @Route { `/info/pod` }
    Text podAll() {
        pod := Pod.of(this)
        return Text.fromPlain("$pod.name $pod.version.toStr")
    }

    @Route { `/info/pod/name` }
    Text podName() {
        Text.fromPlain(Pod.of(this).name)
    }

    @Route { `/info/pod/version` }
    Text podVersion() {
        Text.fromPlain(Pod.of(this).version.toStr)
    }

}

如果这样的方面不存在，我想肯定有很好的理由将路由声明保存在AppModule中，我想知道它们是什么。

Answer 1

在这个(措辞良好的问题)中，我读到了两个不同的子问题：

1. 使用静态方法声明BedSheet路由可以吗？
2. 为BedSheet创建路由面可以吗？

这两个问题的共同主题是持续的清晰和维护.这可能是一个相当个人的“事情”，并且，就像众所周知的猫，有不止一种方法来剥它的皮。

无论如何，要单独处理这些问题：

q)。使用静态方法声明BedSheet路由可以吗？

a)。是的，很好(但是继续读.)

q)。为BedSheet创建路由面可以吗？

a)。简而言之，是的。在很长时间里..。

正如这个问题所暗示的-- BedSheet和IoC都没有声明服务或路由处理程序方法的任何方面。这在很大程度上是因为人们认为这类方面和相关服务不够“核心”，不足以包括在框架中。

在AppModule中保持路由和服务的配置意味着很容易找到和跟踪--特别是对于代码库的新手来说。

在大型项目中，通过facets 进行的非集中化配置可能会引起一些维护上的麻烦。因为如果使用方面，只有通过文本搜索才能发现您拥有的服务。这同样适用于路线。一个新来的人，试图理解这个项目，将不得不涉水通过各种网页的搜索结果。然而，只要看一眼AppModule就会预示着同样的理解。

选择可以这个词是有意的，因为经过足够的编码努力(无论是类命名还是目录结构)，服务和路由就会按逻辑分组，并且很容易找到。

Tales框架有声明路由的方面，但在外化路线中有关于它们的说明

将路由和方法定义为方面是很酷和快速的，但它有以下缺点：

1. 没有明确规定路线将被取走的顺序
2. 你不能在一个地方看到你的应用程序定义的所有路线。

因此，使用方面来声明服务和路线并不是坏事，只是要小心。尽管如此，我一直在考虑实现一个基于方面的RESTful，类似于贾克斯-RS (Java服务)！

顺便说一句，facet配置的实现非常简单；例如，如果您将一个名为@Service的方面放置在IoC服务类(或混合体)上，那么您只需将以下一行添加到绑定方法中：

const class AppModule {
    static Void bind(ServiceBinder binder) {
        AppModule#.pod.types .findAll { it.hasFacet(Service#) }.each { binder.bind(it) }
    }
}

总括而言：

如果您要单独负责一个代码库，或者正在处理一个较小的项目，那么使用facet就可以了。如果维护是由其他人共享的，或者项目不是简单的，那么我会考虑将配置保留在单个AppModule中，或者保留在由@子模块方面定义的多个模块中。