2

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

所以，现在在第三次迭代中，我非常努力地让它正确。我做的一件有点争议的事情是路由代码。因为一切都是明确的并且不鼓励反射，所以我无法在控制器中搜索某些属性来解析路由。必须在路由级别指定所有内容。在第一次迭代中，这并没有完成，但它使控制器变得非常繁琐和冗长......

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

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

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对模型进行验证的方法。但是，这种“规范”是否属于路由层？路由层应指定哪些限制？什么应该留给控制器来验证？

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

4

2 回答 2

2

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

看看下面的规范。这仅适用于单个控制器中的单个操作：

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..

减少默认情况下代码的另一个想法是为每个默认操作引入一个接口。控制器需要为支持的操作实现接口：

可能是这样的：

public interface ISupportIndex
{
    void Index();
}

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

现在，您可以提供诸如blog.HandlesIndex();,之类的方法blog.HandlesSingleItem();。
这些方法返回的内容与您现有的方法相同，因此可以进一步完善结果。
它们可以设计为仅当控制器实际实现接口时才可用的扩展方法。为了实现这一点，返回类型router.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);
}

work on IControllerRoute<ISupportIndex>，仅在控制器实际支持它的情况下显示。

博客控制器的路由可能如下所示：

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>();

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

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

于 2013-03-01T08:28:23.080 回答
1

是的，恕我直言，路由不应包含有关模型甚至视图的逻辑。

如果你看看现在的轻量级 Web 框架（Nancy 等），路由概念不包括视图链接生成之类的东西。它完全是关于将 URI 模板映射到控制器。这从 ASP.NET 实现中消除了很多“魔力”。

https://github.com/NancyFx/Nancy/wiki/Defining-routes

但是，Nancy 方法仍然需要一些“框架”代码来了解哪些路由可用。因此，它不完全符合您的要求。

于 2013-03-01T08:05:14.147 回答