设计一个Asp.Net MVC应用程序 [英] Designing an Asp.Net MVC application

问题描述

作为该领域的新手，我计划构建一个mvc应用程序.我最初启动了一个Web窗体应用程序，但决定使用MVC应用程序可扩展性和可测试性会更加受益.我选择进行切换的另一个好处是以后可以轻松添加更多功能(而不是将代码烘焙到Web表单页面中).

As a novice to this realm, I am planning on building an mvc application. I had originally started a web forms application but decided the scalability and testability will benefit more with an mvc application. I chose to switch with the added benefit of being easier to add more features later on (instead of having code baked into web forms pages).

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

Now a little about my application, it is an application to stimulate an RPG class builder and moveset. In all simplicity, users can register for a class, and depending on other skills they can register for, they can see a custom move set based on these categories. The way I am envisioning it is I will be able to go back and add more classes and skills later in the database and have users register for this new content immediately once it has been added to the project.

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

Everything lives in normalized tables, so many joint tables do exist. For each new skill or class I add will mean a handful of tables will be added to the database. This speaks to the way the data will be stored, everything and all information about classes, user data, skills, etc will be stored in the database.

我已经设计了开始时需要具备的所有初始数据库表以及所需的功能(主页，查看技能页面，查看移动集页面等).我被困在下一步；我要去哪?我应该首先让我的控制器吗?楷模?意见?设计我的页面布局?我正在征询那些对mvc项目采取类似有机方法的人们的建议.知道我有很多工作要做之前，我在开始时面临分析瘫痪.

I have designed all the initial database tables I will need to have at the start, and functionality I need (a home page, view skills page, view move sets page, etc.). I am stuck at the next step; where do I go? Should I make my controllers first? Models? Views? Design my page layouts? I am asking for advice from people who have taken a similar organic approach to an mvc project. I am facing analysis paralysis on what to start on, knowing I have a lot of work ahead of me.

感谢您抽出宝贵的时间来回答问题.

Thank you for taking your time to answer.

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

I've taken everyone's advise and am putting together a website to learn MVC: http://learnaspnetmvc.azurewebsites.net

推荐答案

我可以给您的最重要建议是: start .大型项目似乎不堪重负，尤其是当您像大型项目一样看待它时.相反，将其分解为可完成的小任务.找到您现在可以做的事情，功能的最小子集，然后做.然后做下一个.还有下一个.

The most important advice I can give you: just start. A big project can seem overwhelming, especially when you're looking at it like a big project. Instead, break it into small achievable tasks. Find something you can do right now, the ever-so-smallest subset of functionality, and do it. Then do the next one. And the next.

也就是说，我将告诉您我的个人流程.当我开始一个新的应用程序或一个应用程序片段时，我首先喜欢创建自己的模型.这样，我就可以处理它们之间的交互，充实关系，并以一种有点低压，易于使用的方式来考虑我的应用程序的需求.我还使用代码优先，而您已经创建了数据库表.有些人喜欢这样做.就个人而言，我发现从我的类开始，然后让它们转化为基础数据存储更加有机.从某种意义上讲，它将数据库降级为几乎不存在的层.我不必考虑需要什么数据类型，应该索引什么，不应该索引什么，查询将如何工作，我需要哪种存储过程等等.这些问题都有其时间和地点-新生的发展阶段不是那个时间和地点.您想给自己的大脑一个玩创意的地方，而上课是一种廉价且低摩擦的媒介.如果某个想法无法解决，请丢下课程，然后创建一个新的想法.

That said, I'll tell you my personal process. When I start on a new application or piece of an application, I first like to create my models. That way I can play with the interactions between them, flesh out the relationships, and think about the needs of my application in a somewhat low-pressure, easily disposable way. I also use code-first, whereas you've gone an created your database tables already. Some people prefer to do it that way. Personally, I find starting with my classes and letting those translate into an underlying data store much more organic. In a sense, it relegates the database to almost a non-existent layer. I don't have to think about what datatype things need to be, what should be indexed and what shouldn't, how querying will work, what kind of stored procedures I need, etc. Those questions have their time and place -- the nascent development stage is not that time and place. You want to give your brain a place to play with ideas, and classes are a cheap and low-friction medium. If an idea doesn't work out, throw the class away and create a new one.

一旦有了我的模型，我接下来就想打我的控制器.这使我开始看到自己的模型正在运行.我可以研究应用程序的实际流程，并查看类的实际工作方式.然后，我可以在必要时对模型进行更改，添加其他功能，等等.我还可以开始使用视图模型，并弄清楚应该或不应该将哪些数据传递给视图，以及如何显示这些数据(我需要一个下拉列表吗?等等)，等等.因此，这自然使我进入了自己的观点.再次，我正在测试我的想法.对于每个新层，我将通过更好地了解它的工作方式来强化前一个层.

Once I have my models, I like to hit my controllers next. This lets me start to see my models in action. I can play around with the actual flow of my application and see how my classes actually work. I can then make changes to my models where necessary, add additional functionality, etc. I can also start playing around with view models, and figuring out what data should or should not be passed to the view, how it will need to be displayed (will I need a drop down list for that? etc.), and such. This, then, naturally leads me into my views. Again, I'm testing my thinking. With each new layer, I'm hardening the previous by getting a better and better look at how it's working.

此过程的每个阶段都是非常流动的.一旦开始使用控制器，我将将进行模型更改.一旦我提出了意见，就需要调整控制器，也许还需要调整模型.您必须给自己自由，让自己搞砸了.不可避免地，您会忘记某些东西，或者以头脑笨拙的方式设计一些东西，只有深入学习之后才能看到.再次，这就是代码优先的美妙之处.到目前为止，我什至没有数据库，所以我所做的任何更改都没什么大不了的.我可以完全销毁所有东西，然后以完全不同的方式进行操作，而不必担心更改表，迁移数据等问题.

Each stage of this process is very liquid. Once I start working on my controllers, I will make changes to my models. Once I hit the views, the controllers will need to be adjusted and perhaps the models as well. You have to give yourself the freedom to screw up. Inevitably, you'll forget something, or design something in a bone-headed way, that you'll only see once you get deeper in. Again, that's the beauty of code-first. Up to this point, I don't even have a database, so any change I make is no big deal. I could completely destroy everything I have and go in a totally different way and I don't have to worry about altering tables, migrating data, etc.

现在，到此为止，我的模型是非常静态的，这就是我进行数据库创建和初始迁移的时间.虽然，即使是现在，实际上，只是因为这是必需的，我才可以在浏览器中实际启动它以查看我的视图.您以后总是可以进行迁移，但是一旦使用了具体的东西，摩擦就会开始增加.

Now, by this point my models are pretty static, and that's when I do my database creation and initial migration. Although, even now, really, only because it's required before I can actually fire this up in a browser to see my views in action. You can always do a migration later, but once you're working with something concrete, the friction starts to increase.

既然我看到了他们的生活，我将倾向于对我的控制器以及我的观点进行一些调整.一旦我对所有事情都满意，便开始研究优化和重构-如何使代码更有效?更具可读性?更高效?我将使用瞥见之类的工具来查看我的查询，渲染时间等，然后对事情做出决策像存储过程之类的.

I'll tend to do some tweaking to my controllers and obviously my views, now that I'm seeing them live. Once I'm happy with everything, then I start looking at optimization and refactoring -- How can I make the code more effective? More readable? More efficient? I'll use a tool like Glimpse to look at my queries, render time, etc., and then make decisions about things like stored procedures and such.

然后，只需大量冲洗并重复一次.请注意，这都是非常零碎的.我没有构建应用程序；我正在构建一个类，然后是另一个类，然后是HTML，等等.您只专注于下一部分，需要转移到下一小部分的那一小块，而且不那么令人头疼.因此，就像我开始时一样，我将关闭它: start .作家有一句话，最难的是第一句话.这并不是因为第一句话真的那么难.这是因为一旦您掌握了这一点，就写下了第二句话，然后写下了第三句话，在您不知不觉中就写下了几页文字.最难的是开始.一切都从那里流淌.

Then, it's just a lot of rinse and repeat. Notice that it's all very piecemeal. I'm not building an application; I'm building a class, and then another class, and then some HTML, etc. You focus on just that next piece, that small chunk you need to move on to the next thing, and it's much less overwhelming. So, just as I began, I'll close the same: just start. Writers have a saying that the hardest thing is the first sentence. It's not because the first sentence is really that difficult; it's because once you get that, then you write the second sentence, and the third, and before you know it, you've got pages of writing. The hardest part is in the starting. Everything flows from there.

这里的其他答案提供了很好的建议和重要的信息，但我认为在现阶段，这对您不利.我是第一个提倡最佳实践，对应用程序进行适当分层等的倡导者.但是，最终，一个不遵循任何规则的完整应用程序比包含所有这些功能的不完整应用程序更有价值.值得庆幸的是，我们正在使用可延展的媒介-数字文本-而不是石头.您可以随时更改事物，以后再进行改进.您可以返回并将您的应用程序分离到适当的层，创建存储库和服务以及其他抽象，添加控制和依赖注入的反转，等等.，但这是因为我们已经做了一段时间了.我们知道如何做这些东西-很多时候我们已经有了用于这些东西的类和库.但是，对于刚起步的人或处于新生阶段的应用程序来说，它可能会令人崩溃.不仅要开发应用程序，还需要花费数天或数周的时间来浏览建议，实践，库等，以尝试掌握所有内容，最终您什么也没真正要展示.不必担心做正确的事并做某事.然后，重构直到正确.

The other answers here have great advice and important nuggets of information, but I think they do you a disservice at this stage. I'm the first to advocate best practice, proper layering of your applications, etc. But, ultimately, a complete app that follows none of this is more valuable than an incomplete app that incorporates it all. Thankfully, we're working with a malleable medium -- digital text -- and not stone. You can always change things, improve things later. You can go back and separate your app out into the proper layers, create the repositories and services and other abstractions, add in the inversion of control and dependency injection, etc. Those of us who have been doing this awhile do that stuff from the start, but that's because we've been doing this awhile. We know how to do that stuff -- a lot of times we already have classes and libraries we drop in for that stuff. For someone just starting off, or for an app in its earliest nascent stage, it can be crippling, though. Instead of just developing your app, you end up spending days or weeks pouring through recommendations, practices, libraries, etc. trying to get a handle on it all, and by the end you have nothing really to show for it. Don't worry about doing things right and do something. Then, refactor until it's right.

这篇关于设计一个Asp.Net MVC应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！