设计Asp.Net MVC应用程序

Question

作为这个领域的新手，我正计划构建一个mvc应用程序。我最初创建了一个Web表单应用程序，但决定使用mvc应用程序可扩展性和可测试性将受益更多。我选择切换的另一个好处是以后更容易添加更多功能（而不是将代码烘焙到Web表单页面中）。

现在关于我的应用程序，它是一个激发RPG类构建器和移动集的应用程序。简而言之，用户可以注册课程，并且根据他们可以注册的其他技能，他们可以看到基于这些类别的自定义移动设置。我想象的方式是我将能够返回并在数据库中稍后添加更多类和技能，并让用户在将新内容添加到项目后立即注册。

所有东西都存在于规范化的表中，因此确实存在许多联合表。对于我添加的每个新技能或类，将意味着将少量表添加到数据库中。这说明了数据的存储方式，所有关于类，用户数据，技能等的信息都将存储在数据库中。

我已经设计了我需要在开始时拥有的所有初始数据库表，以及我需要的功能（主页，查看技能页面，查看移动设置页面等）。我被困在下一步;我要去哪？我应该先制作控制器吗？楷模？看法？设计我的页面布局？我正在向那些对mvc项目采取类似有机方法的人征求意见。我正面临分析瘫痪的问题，因为我知道自己有很多工作要做。

感谢您抽出宝贵时间回答。

---

我已经采取了所有人的建议，并正在组建一个网站来学习MVC：http://learnaspnetmvc.azurewebsites.net

Answer 1

我能给你的最重要的建议：只需开始。一个大项目看起来势不可挡，特别是当你像大项目那样看待它时。相反，将其分解为可实现的小任务。找到你现在可以做的事情，这是迄今为止最小的功能子集，并且可以做到。然后做下一个。接下来。

那就是说，我会告诉你我的个人过程。当我开始使用新应用程序或应用程序时，我首先想要创建我的模型。通过这种方式，我可以发挥它们之间的相互作用，充实关系，并以一种低压，易于丢弃的方式思考我的应用需求。我也使用代码优先，而你已经创建了数据库表。有些人喜欢这样做。就个人而言，我发现从我的课程开始，让那些转化为基础数据存储更加有机。从某种意义上说，它将数据库降级为几乎不存在的层。我不必考虑需要做什么数据类型，应该索引什么，不应该做什么，查询将如何工作，我需要什么样的存储过程等等。这些问题有他们的时间和地方 - 新生的发展阶段不那个时间和地点。你想让你的大脑有一个玩思想的地方，而且课程是一种廉价且低摩擦的媒介。如果一个想法没有成功，那就扔掉课堂并创建一个新课程。

有了我的模特，接下来我想打开我的控制器。这让我开始看到我的模型在行动。我可以使用我的应用程序的实际流程，看看我的类实际上是如何工作的。然后，我可以在必要时更改我的模型，添加其他功能等。我还可以开始使用视图模型，并确定应该或不应该将哪些数据传递给视图，以及如何显示它们（我需要一个下拉列表吗？等等）。那么，这自然会引导我进入我的观点。再一次，我正在测试我的想法。对于每个新图层，我通过更好更好地了解它的工作方式来强化之前的图层。

这个过程的每个阶段都非常流动。一旦我开始使用我的控制器，我将对我的模型进行更改。一旦我点击视图，控制器将需要调整，也许还需要调整模型。你必须给自己搞砸自由。不可避免地，你会忘记某些东西，或者以一种骨头的方式设计一些东西，只有在你深入了解之后才能看到它。再次，这就是代码优先的美。到目前为止，我甚至没有数据库，所以我做的任何改变都没什么大不了的。我可以彻底摧毁我所拥有的一切，并以完全不同的方式进行，我不必担心改变表格，迁移数据等。

现在，到目前为止，我的模型非常静态，而且在我进行数据库创建和初始迁移时也是如此。虽然，即使是现在，实际上，只是因为它需要才能在浏览器中实际启动它以查看我的观点。您可以随时进行迁移，但是一旦您处理了具体的事情，摩擦就会开始增加。

我倾向于对我的控制器进行一些调整，显然是我的观点，现在我已经看到它们了。一旦我对所有事情感到满意，那么我就开始关注优化和重构 - 如何使代码更有效？更具可读性？更高效？我会使用像Glimpse这样的工具来查看我的查询，渲染时间等，然后就存储过程等事情做出决定。

然后，它只需要大量的冲洗和重复。请注意，这一切都非常零碎。我没有建立申请;我正在构建一个类，然后是另一个类，然后是一些HTML，等等。你只关注下一个片段，那个小块你需要继续下一件事，而且它要少得多压倒。所以，就在我开始的时候，我会关闭它：只需开始。作家有句话说最难的是第一句话。这不是因为第一句话确实那么困难;它是因为一旦你得到它，那么你写第二句，第三句，在你知道它之前，你已经有了写作的页面。最困难的部分是在开始。一切都从那里流过。

这里的其他答案都有很好的建议和重要的信息，但我认为它们在这个阶段对你有害。我是第一个倡导最佳实践，正确分层应用程序等的人。但是，最终，一个完全没有这个应用程序的应用程序比不完整的应用程序更有价值。值得庆幸的是，我们正在使用可塑性的媒介 - 数字文本 - 而不是石头。你总是可以改变事物，以后改进。您可以返回并将应用程序分离到适当的层，创建存储库和服务以及其他抽象，添加控制和依赖注入的反转等等。我们这些已经做了一段时间的人从一开始就做这些事情，但那是因为我们已经做了一段时间。我们知道如何做这些事情 - 很多时候我们已经有类和库我们为这些东西投入。对于刚刚开始的人，或者在最初的初期阶段的应用程序，它可能会瘫痪。您最终需要花费数天或数周的时间来尝试处理所有内容，而不是仅仅开发您的应用程序，最终您没有真正展示它。不要担心做正确的事情并做某事。然后，重构直到它正确。

Answer 2

作为规划MVC框架应用程序的第一步，我们应该从一个强大的模型（典型的C＃道具）开始。基于我们需要首先了解业务，然后了解不同工作流和实体之间的关系这一事实，这个过程将耗费大部分时间。因此，商业模式随着时间的推移而发展。因此，花费定性时间来构建此层，但不要过多。

一旦域（业务）模型准备就绪，在我们真正开始编写Repository类之前，我们应该定义我们的Repository Contracts，它们通常是Interfaces。合同可以帮助所有各方（其他组件）以完全相同的方式相互交互。然后我们在Repository组件上实现契约，它就像你的持久性媒介（比如数据库）中的PUSH和PULL数据一样。记住存储库组件永远不会对业务逻辑有任何想法。

一旦建立了后端，我们就可以专注于实际的业务流程实施。我们可以定义另一个级别的Contract，它定义了使用Model类完成的所有业务操作。此接口由BusinessLogic Component实现，该组件执行核心业务活动（每个业务操作的特定方法）。此特定组件将使用Repository组件将业务数据委派给持久性介质。

完成上述步骤后，我们可以轻松地构建控制器。我们应该在控制器中调用业务逻辑组件方法并完成工作。完成控制器后，我们可以定义视图和其他UI元素，如部分视图等。

流程的

Pictorial representation如下 -

Answer 3

简单的架构（从高级别到低级别）

1. 表示层
2. 域逻辑层
3. 数据访问层
4. 数据库

演示文稿图层是包含视图，控制器和可选视图模型的MVC项目。

域逻辑图层是表示层将访问的类库项目（通过DLL或服务引用）。该层包含应用程序的业务逻辑和规则。

数据访问图层可能包含两个子图层 -

1. <强>存储库即可。用户存储库是任何长期应用程序的最佳实践。

2. 实体框架模型。 这将与数据库进行通信。

数据库你已经拥有。

Answer 4

我建议阅读Scott Millet的一本名为“专业ASP.NET设计模式”的书 ISBN：0-470292-78-4
Scott从架构的角度来看看一个好的ASP.NET站点应该是什么样子 - 即DataAccess层，业务逻辑层，表示层，域事件等。

通过遵循行业标准，您将更好地了解如何正确组建MVC网站。

希望这有帮助。

Answer 5

我建议你在ASP.NET Web API附近制作你的MVC应用程序，因为如果你以后再去购买移动应用程序，它会有所帮助。

由于您是MVC新手，您应该在社区老年人共享的MVC上下载一些开源项目。研究两到三个项目，并分析最适合您的解决方案。

快速谷歌搜索将带您进入一些好项目。 例如 Making a simple application，Prodinner

之后你还应该通过MSDN tutorial on MVC 5 app with SSO 来启用社交登录。