抽象 CRUD 控制器是个好主意吗？

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

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

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

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

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