20130827 MHC的MVC之路

　　从5月底开始，觉得要学些东西了，重新拿起MVC（此时已经是4）看了起来。心里暗想着这次要坚持。买了很多书，一些源码，但觉得这还不够。想要有动力能坚持学下去，对我来说，必须要有实际的项目支持，可这种大事怎么是我能说了算的？于是把MHC的代码COPY了一份，把WEB层删了重新建立，去掉所有工程与TFS的联系，开始连学习带编码。目前看来效果很好，断断续续的还在坚持，有思考，有成果，有深入。

　　但有一个问题一直萦绕着心头：因为我仅仅是想把原项的功能照搬，结构不想改变。实践的过程中麻烦重重，问题的根源就在于MHC是基于WebForm。我一直在思考这个问题：在我们选择某种技术编写WEB程序后，缺斤短两的设计文档，客户需求，会给开发人员高度的自由，最后整个网站的结构一定会想所基于的技术结构靠拢。其实不只是MHC，从Conductor branch出来的几个项目，无不带有浓重的“WinForm”风。因为WebForm本就是效仿WinForm而诞生的，其灵魂就是倚仗一个或多个看不见的“状态”，来实现一个页面堆积多种功能，复杂无比。而现在MVC则与之差之千里，如果我所有结构都照搬，必然要吃尽了苦头。比如我现在正在修改的一个页面，本身设计的领域模型十分的简单，就是一堆被称作Plan的字符串，在数据库中对应一个ID，一个Name。可正因为简单，在原项目中我生怕这个界面太简单了...把增删改都集中在此页面中，列表有分页，还有复杂的查询...现在好了，我不知道MVC中要怎么处理这个家伙了。如果把Edit和Delete功能分到其他页面去会简单很多（也许这才是符合REST的设计），可我又不太想这么做，怎么办？

注：实际上有人会觉得使用Ajax不就好了？...没错，但我想把各种情况都试一下，例如这种带有查询和分页的功能页面在项目中有4-5个，我会各自使用不同的风格来实现，包括分页的方式，以达到学习的目的，所以我要把Ajax留给后面一个功能点Order List，如果在那里运用的比较成功，我会返回头再重新考虑现在这个Plan List页面的解决方案，这就是我目前采取的迭代式学习模式。

　　我想，如果我有权利设计网站结构，我会将Edit和Delete功能分出去的，但现在我的主要目标还是学习。我想看看其他项目，那种真实的运作在production的项目是怎么处理这种事情的（至少MusicStore是单功能单页）,是否还是用了基于.NET MVC之上的小型框架？我想我还是没法躲避单页面功能很多的情况，毕竟，一些使用MVC 架构 大型的网站就是这样的。

　　另外，在github上搜索MVC C#语言，能找到那么多那么多的好东西，真是很令我兴奋。这些甚至小到４０４ＮｏＦｏｕｎｄ的解决方案，都是我在学习过程中思考并且苦恼过的，如果有时间应该多看看这些。

 

　　后记：我最终还是选择了Ajax方式，后面一篇开头有提到 http://www.cnblogs.com/apodemakeles/p/3287993.html

转载于:https://www.cnblogs.com/apodemakeles/p/3285934.html