我使用Zend框架和学说在此应用程序MVC设计问题
在我的web应用程序我有这样的活动，会议，案例分析各种单独的模块..所以我在这一刻让控制器的设计。在下面的图像管理文件是控制器及其子是它的行为。所以监管文档，视频，播客都具有几乎相同的功能。那么这个设计是否合适？ 在每个动作的mvc中，我将拥有一个单独的视图。而在用户类型上，我可能不得不将访问级别放在这些模块上。所以我保持单独的控制器，以便我可以轻松地控制每个用户类型的模块。但是这会导致重复的代码。
现在我想做出一个父类和我将所有的常用方法。例如。我将拥有普通的班级资源，并且我将保留列表，搜索，建议，添加，收藏等。这将成为上述给定控制器的父项。
因此，如果我采用这种方法，我将如何管理所有这些不同模块的视图..？如果我用这个比我的代码会有点凌乱..？
如果我正确地理解了你，你在监管文件，视频和播客之间有一系列共同行为。
在这种情况下，您应该尝试将共同点抽象为从这三个区域继承的父类。
作为一个例子，我有我自己的MVC框架，我定义了一个超类tnh_controller，我的其他控制器（例如：venue_controller，group_controller）从其继承。在父控制器中，我定义了header（）和footer（）和delete（）方法。然后，我可以使用那些在孩子班级中保持不变的东西，并省下一些努力。
您也可以在模型超类中为您的模型（CRUD）执行一些常见工作，只需根据需要覆盖它即可。大多数不同模型的逻辑来自类变量（表名，列名等）。
我不会过分担心“严格”的MVC。相反，试着弄清楚什么会节省你的时间，并保持你的代码组织。这听起来像是你在正确的轨道上将类似的行为放在父母层面。
MVC设计意味着对于每个视图，您都有一个控制器和一个模型。但是，模型根本不需要是类，也不需要为每个MVC创建不同的模型。通常你会在一些MVC之间共享一个模型，或者你的模型可能只是你在自己的控制器中定义的整数值。通常情况下，你甚至可能要共享它们之间的数据，那么你将有一个单例模式：
你仍然可以有一个单独的控制器包含建议，为收藏的行动，而不必让它的父类为所有的控制器。基本上，与这些相关的UI元素可以渲染为部分视图并调用相关控制器中的操作。这样你可以摆脱视图的问题。
我会建议让所有的控制器在模块中都有漂亮的URL和清晰的结构，但是要保持控制器的精简。将您的域逻辑放入服务或实体中，因此不需要（或者更少）代码重复。
更多在：
从DDD：
控制器属于应用层/域逻辑属于域层
你可以举一个“杂乱”代码的例子吗？你能更具体地说明你担心的是什么吗？ –