我刚开始学习 ASP.NET。我在 uni - chess 有一个项目（/w 下棋算法，alpha-beta 修剪）。我决定在 ASP.NET 中实现它来学习。
这是我的问题：模型应该做什么，控制器应该做什么？我猜这个视图将只是一个显示棋子和一些信息的模板。
我看到一个人的应用程序，他将几乎所有逻辑都放入控制器中。游戏逻辑不应该交给模型吗？我相信该应用程序的运行方式如下：
那么...您将如何在 ASP.NET MVC 4/4.5 中实现国际象棋游戏？
正如@usr 所建议的那样，MVC 背后的原因是将表示层与业务逻辑层分开（以提高可测试性、可维护性等）。
在您的情况下（就像在所有软件项目中一样），这实际上取决于您希望在解决方案中投入的时间和精力。
如果您想快速创建一些东西或对一个想法进行原型设计，那么继续将所有逻辑放入控制器中，您将很快并证明您的代码至少可以工作。
当项目增长或需要维护时，您会意识到这种方法带来的痛苦大于好处：代码分散，逻辑稀疏。然后，需要更多努力的下一步是将来自控制器的知识提炼或重构为一组负责一般国际象棋游戏的类（领域模型）。
通过这种方式，您实现了一个重要目标：将项目的整个逻辑封装到一个可管理、可维护和可重用的库中，可能被指定主项目可用 API 的意图揭示接口包围。
然后，这个主要项目可以是桌面应用程序、移动应用程序、MVC 应用程序，无论您怎么想：一个围绕功能齐全且强大核心的瘦客户端。
在此设计中您将不得不面对一些决定：例如，核心中的类通常与 MVC 应用程序中的模型不同（它们通常是 POCO 对象，尽管它们不是必须的）；因此，您必须决定是要选择可以在两者之间映射的适配器，还是选择更简单的解决方案，将核心中的类用作 MVC 中的模型。
另一个问题可能是关于如何管理持久性（保存到数据库）的决定。
绝对不要忘记的是围绕核心 API 进行的一组很好的测试：它们将定义和记录其行为，并将在重构期间证明是无价的帮助。
模型定义了您的应用程序中使用的数据结构。视图定义了数据的视觉呈现方式。控制器管理所有逻辑和用户交互处理。
大多数应用程序逻辑应该进入您的控制器类。
任何与渲染 UI 相关的事情都应该进入你的视图。在您的情况下，使用 ASP.NET MVC，您的视图应定义 HTML 页面布局和结构以及将模型对象中的值插入正确的 HTML 元素和属性所需的代码。
数据存储和检索操作应该进入您的模型，任何模型转换、操作等也应该如此。
也许你很困惑view model并且business model. 视图模型只包含要呈现（或被接受为输入）的数据。它通常不包含任何逻辑。两种形式可以共存。大多数情况下，它们表示为不同的 .NET 类集，甚至可能在不同的命名空间或程序集中。
商业模式可以为所欲为。您可以在那里对板子、零件等进行建模。您的国际象棋引擎可以在商业模型上运行。所有这些都与表示层无关。
在数据库驱动的应用程序中，业务模型很可能是您与 ORM 一起使用的实体类。
当您想要展示时，您可以从业务模型构建视图模型。