c# - 对于路由代码中指定的 Controller /方法来说，使用 "specifications"是不是很糟糕？

Question

我正在为 ASP.Net 设计一个替代的 MVC 框架。我对该框架的部分目标是尽可能减少“魔力”。我唯一的反射(reflection)是将表单、查询字符串等绑定(bind)到普通的 ol' 类(带有一些用于忽略、转换等的可选属性)。因此，我绝对不进行类/方法检测。一切都必须非常明确。我已经经历了大约 3 次 API“形状”迭代。前两个实现了我没有魔法的目标，但它非常冗长且不易阅读......并且 Controller 通常必须完成 MVC 框架应该做的繁重工作。

所以，现在在第三次迭代中，我正在非常努力使其正确。我所做的一件稍微有争议的事情是路由代码。因为一切都是明确的并且不鼓励反射，所以我无法在 Controller 中搜索某些属性来解析路由。一切都必须在路由级别指定。在第一次迭代中，这并没有完成，但它导致了极其麻烦和冗长的 Controller ......

现在，我有这个流畅的 API 来指定路线。它有点超出了我最初的想象，现在作为一种方式来指定 Controller 的方法能够做什么以及它应该接受什么。

进入实际代码。实现是无关紧要的。您真正需要知道的唯一一件事是涉及很多泛型类型。因此，这里是一些路由的快速示例:

var router=new Router(...);
var blog=router.Controller(() => new BlogController());
blog.Handles("/blog/index").With((ctrl) => ctrl.Index());
blog.Handles("/blog/{id}").With((ctrl,model) => ctrl.View(model["id"])).WhereRouteLike((r) => r["id"].IsInteger()); //model defaults to creating a dictionary from route parameters
blog.Handles("/blog/new").UsingFormModel(() => new BlogPost()).With((ctrl, model) => ctrl.NewPost(model)); //here model would be of type BlogPost. Also, could substitue UsingRouteModel, UsingQueryStringModel, etc

还有一些其他方法可以实现，例如 WhereModelIsLike 或一些对模型进行验证的方法。然而，这种“规范”属于路由层吗？路由层应指定哪些限制？哪些内容应该留给 Controller 来验证？

我是不是让路由层担心太多了？

Answer 1

我认为路由太冗长了。我不想为 20 个 Controller 编写这种代码。特别是，因为它确实是重复的。
我在这里看到的问题是，即使是默认情况也需要详细的声明。这些详细的声明仅在特殊情况下才需要。
它具有表现力和可读性，但您可能需要考虑打包高级功能。

请查看以下规范。这仅适用于单个 Controller 中的单个操作:

blog.Handles("/blog/new")
    .UsingFormModel(() => new BlogPost())
    .With((ctrl, model) => ctrl.NewPost(model))
    .WhereModelIsLike(m => m.Status == PostStatus.New);

仅稍微减少代码量的一种方法是允许指定根文件夹:

var blog=router.Controller(() => new BlogController(), "/blog");
blog.Handles("index").Wi..
blog.Handles("{id}").Wit..
blog.Handles("new").Usin..

减少默认情况代码的另一个想法是为每个默认操作引入一个接口(interface)。 Controller 需要实现支持操作的接口(interface):

可能是这样的:

public interface ISupportIndex
{
    void Index();
}

public interface ISupportSingleItem
{
    void View(int id);
}

现在，您可以提供类似 blog.HandlesIndex(); 的方法, blog.HandlesSingleItem(); .
这些方法返回与现有方法相同的内容，因此可以进一步细化结果。
它们可以被设计为扩展方法，只有在 Controller 实际实现接口(interface)时才可用。为了实现这一点，返回类型为 router.Controller需要是一个协变接口(interface)， Controller 作为通用参数，即像这样:

IControllerRoute<out TController>

例如扩展方法HandlesIndex将像这样实现:

public static IRouteHandler HandlesIndex(
    this IControllerRoute<ISupportIndex> route)
{
    // note: This makes use of the "root" as suggested above:
    // It only specifies "index", not "/someroot/index".
    return route.Handles("index").With(x => x.Index);
}

致力于 IControllerRoute<ISupportIndex> ，仅在 Controller 实际支持的情况下显示。

博客 Controller 的路由可能如下所示:

blog.HandlesIndex();
blog.HandlesSingleItem();

// Uses short version for models with default constructor:
blog.HandlesNew<BlogPost>().UsingFormModel();
// The version for models without default constructor could look like this:
//blog.HandlesNew<BlogPost>().UsingFormModel(() => new BlogPost(myDependency));

添加验证规则也可以更加简洁:

blog.HandlesNew<BlogPost>().UsingFormModel()
    .When(m => m.Status == PostStatus.New);

如果规范更复杂，可以将其打包在实现 IModelValidation 的自己的类中。现在使用该类:

blog.HandlesNew<BlogPost>().UsingFormModel()
    .WithValidator<NewBlogPostValidation>();

---

我的所有建议都只是让您当前的方法更容易处理的方法，所以我想到目前为止，它并没有真正回答您的实际问题。我现在这样做:

我喜欢我的 Controller 尽可能干净。在我看来，将验证规则放在路由上非常好，因为 Controller 操作现在可以假设仅使用有效数据来调用它。我会继续采用这种方法。