我想检查一下我的知识，因为我在公司看到了一个不同的项目。

我所知道的是，如果我们想在项目中使用MVC软件设计模式，我们可以这样分开我们的项目：

视图部分是我们的设计界面，即WPF中的ui.xaml文件，winforms中的ui.designer.cs，android中的ui.xml，qtsquick中的ui.qml，xcode中的ui.ui。

控制器部分是与具有相似名称的设计器文件连接的最近的源文件。这是wpf中的ui.xaml.cs文件，winforms中的ui.cs，android中的ui.java，qtsquick中的ui.h/ui.cpp，xcode中的ui.swift。

模型部分是执行主操作的任何其他类。我通常在它们后面加上后缀Manager(或类似的东西)，说明它的责任是什么。

对于mvvm，我还使用一个interface或abstract class，该视图是从其视图模型部分继承的，并将我以前的控制器视为视图的一部分。

一个项目就足够建造整个建筑了。

但是我公司的一个项目有很多课程！一个名为usercontrol的设计器的单独库的文件夹，另一个名为view的单独库的文件夹，以及另一组名为viewmodel的库，控制器和模型也是如此。他们说它是MVC和MVVM的混合物。最令人惊讶的一点是，整个软件有38个独立的项目，由一个程序员编写，团队规模很小。

请告诉我我的知识是否正确？请告诉我，我公司的项目方向是否正确？

您对MVC和MVVM模式的了解是否正确？你在控制器(viewmodel)上犯了一个错误，我认为模型也是这样。

你的项目方向正确吗？似乎不对。

我们使用所有视图和视图模型类的接口(MVC中的控制器也是如此)，只是为了更好地管理依赖关系。它被称为IOC(控制反转)，我们经常使用的技术被称为依赖注入(dependency injection)，这使得类只依赖于接口(而不是具体的实现)，使用服务定位器或某种服务查找对象。

首先，您可以将Controller与MVVM混合使用来处理逻辑代码，并让ViewModel为视图处理数据模型的绑定和表示，请在代码项目中查看以下系列：http://www.codeproject.com/articles/173618/mvvm-sharp-epset-1

但我不是MVCVM的忠实粉丝，除非你能充分利用它的优势。

控制器或视图模型是从视图中分离出来的类，我们把逻辑代码放在它们中。例如，"ui.xaml.cs"不是控制器。该文件只是ui.xaml类的另一个文件。它们都是我们称之为视图的同一类。记住，我们使用表示模式将逻辑代码与视图的代码隐藏代码分开。

模型是属性组合在一起的对象。我们只是尽量不要把模型类和任何逻辑代码混合在一起。模型可以有验证函数(.isnamevalid()或其他一些函数来创建对象的另一种表示形式(.toString()例如)，但不能有任何逻辑代码(例如cruds)。我们不把主要业务放在模型中。主要操作在控制器(视图模型)中，但结果可能是我们绑定到某些视图字段的模型。

单击"搜索用户"按钮，search user命令在控制器中运行一个函数，结果将用户模型对象设置为名为founduser(位于控制器中)的属性，视图的文本框显示founduser的名称。

在每个应用程序中，当涉及到表示层时，您可以使用多个设计模式，MVC、MVP、MVVM等。但是，在表示层中遵循一个设计模式是最佳实践，因为它是一致的，并且更易于维护。

另外，我认为您对模型和控制器定义有一些误解，通过解决这些误解，您可以更好地理解模式。