asp.net-mvc - 抽象 CRUD Controller 是个好主意吗？

Question

我们正在使用 ASP.NET MVC 开发一个相当大的应用程序，一开始我们发现拥有一个具有常见 CRUD 操作(新建、保存、删除...)以及默认列表的抽象基本 Controller 可能很有用行动。在我们的例子中，我们有 20 多个实体通过这种 Controller 进行管理。

这有效并避免了重复一些代码并使应用程序更加同构，但是当您看到 Controller 时很难准确地看到它实现了哪些操作，并且它可能实现了一些不应该存在的操作。例如，假设您想要编辑传递名称而不是 id，则必须创建一个新的 EditByName(name)，即使这样做，您仍然可以使用 Edit(id) 操作，因为它位于基础中。

对我来说，整个事情对我来说有点味道，但我没有找到任何显示替代方案的示例，因为我看到的 MVC 应用程序的领域非常狭窄。有什么建议吗？有什么例子吗？ (我不一定使用 ASP.NET MVC，我认为这个问题对于任何 MVC 框架来说都是非常普遍的)。

Answer 1

在某些方面我认为这是一个好主意，但在其他方面我认为这是对继承的滥用。我确实有一个公共(public)基础 Controller ，但它存在是因为我将 Controller 中的公共(public)代码重构到其中，而不是先验地设计的。如果您的实体足够相似，以至于您在基本 Controller 中共享的代码超过了您被迫拖来拖去的代码，那么也许这是值得的。另一方面，如果共享的代码相当少，并且只是调用一个完成工作的私有(private)抽象方法(以便您无论如何都在真正的 Controller 中实现它)，我不知道它会给您带来什么。无论如何，您都不会直接实例化 Controller (除了在测试中)，因此拥有超出框架所需的通用接口(interface)并不那么重要。

我的投票是将那些真正常见或交叉关注的事情重构到基类中，而不是试图强制建立可能并不真正存在的“is-a”关系。