Ⅰ MVC模式的优点及缺点有哪些
说说Mvc的优缺点
优点:
1.各施其职，互不干涉
在MVC模式中，三个层各施其职，所以如果一旦哪一层的需求发生了变化，就只需要更改相应的层中的代码而不会影响到其它层中的代码。
2.有利于开发中的分工
在MVC模式中，由于按层把系统分开，那么就能更好的实现开发中的分工。网页设计人员可以进行开发视图层中的JSP，对业务熟悉的开发人员可开发业务层，而其它开发人员可开发控制层。
3.有利于组件的重用
分层后更有利于组件的重用。如控制层可独立成一个能用的组件，视图层也可做成通用的操作界面。
4.MVC设计模式可以说实现了分层开发。各个层都有各个层的作用。
5.降低了层与层之间的依赖，有利于代码的标准化开发
6.再用新的代码业务逻辑替换时，只需要替换相对应的层，大大降低了我们的工作量，分工明确。
缺点:
1.增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分吵悄瞎离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
2.视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
3.视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
4.目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
5.麻烦，有些代码重复的过多，不利于在实际开发中使用，所以我们要学习框架，下面的鸟瞰图分析了框架在MVC里都替代了哪些层。
Ⅱ 基于ASP.NET MVC框架开发Web论坛应用程序
我想通过本系列文章从头到尾构建一个完整的 MVC论坛应用程序，最终的目的是探讨和推动使用 MVC框架构建应用程序的最佳实践。
1、 简介
在本篇中，我想先从全局方面介绍一下论坛应用程序的总体目标。在本篇中，我将讨论一下避免代码坏味道的重要性，还将讨论如何利用软件设计原则和模式来帮助你编写适合未来改变的富有弹性的代码。最后，我还将论证一下为什么我选择使用测试驱动开发方式构建本系列文章中的论坛应用程序。
2、 什么样的软件是好的软件
我不想仅仅为了构建论坛应用程序而任意构建此论坛应用程序。我的目标是尽可能构建最棒的论坛应用程序。
这个目标立即引发这样一个问题：什么样的软件是好的软件？是什么导致一个应用程序比另一个应用程序更好一些或更差一些呢？在事先没有一个关于“好软件”的定义之前，我无法声明我构建了一禅高个完美的论坛应用程序。
因此，下面是我对于“好软件”的定义。
3、 好软件是设计得易于修改的软件
存在多种原因可能需要你改变
1)你可能需要在一个现有软件上添加新的特征
2)你可能需要修改一个现有软件中的错误
3)你可能需要优化现有软件
4)你可能需要改进现有软件的设计
一般说来，设计糟糕的软件是难于改变的。有些软件设计得如此糟糕，以致于每个人都害怕碰一碰它。我们大家应该都使用过设计得糟糕的软件。当软件不好时，你很希望它干脆走开；甚至如果有机会的话，你可能想从头开始重新编写这款软件。
4、 避免代码坏味道
Robert和Micah Martin把糟糕的软件部分描述为代码坏味道。下列代码轿伏坏味闭袭携道意味着此软件的书写是相当糟糕的：
1)僵化性（Rigidity）—僵化的软件是这样的软件，当你在某个位置作一改动时即要求对系统作出相应的一系列的更改。
2)脆弱性（Fragility）—脆弱的软件是这样的软件，你在某个位置作一改动时即打断另外多处的正常运行。
3)不必要的复杂性—不必要的复杂软件是指过度设计的软件，其目的是为了处理任何可能的改变。
4)不必要的重复—不必要的重复软件中包含大量的重复性代码。
5)晦涩性—晦涩的软件是指难于理解的软件。
【注意】上述这些代码味道在Micah和Robert Martin的着名《Agile Principles,Patterns,and Practices in C#》中得到充分的描述。在此，强烈建议读者读一下这本书。
注意，上述这些代码味道都与所有的代码改变相关联。每一个这些代码味道都将妨碍代码的改变。
5、 软件设计原则
遵循良好的软件设计原则，将有助于编写软件易于适应未来更改的软件。软件设计原则有若干，也不尽相同。例如，Cunningham和Cunningham Wiki描述面向对象设计的11个原则：
。
其中提到的面向对象设计的前五个原则与Robert Martin及他的儿子Micah Martin编着的《Agile Principles,Patterns,and Practices in C#》中所主张的软件设计原则是一致的。此外，Robert Martin还在Object Mentor开辟的博客上讨论了这些原则：
。
此外，我还发现有另外两本书中也提供了有关软件设计原则的极其有用的信息。第一本是Eric Freeman,Elisabeth Freeman, Kathy Sierra, Bert Bates编着的《Head First Design Patterns》；第二本是Brett McLaughlin,Gary Pollice和David West编着的《Head First Object-Oriented Analysis and Design》。尽管这些书所讨论的原则与Robert Martin的提法并不十分相同，但是它们却十分相近。
不过真实的情况是，上述所有这些针对软件设计原则展开讨论的资源都源自Robert Martin的工作。Robert Martin并不是所有原则的发明者，但是他的确是第一个把这些原则收集到一起的人。下面列出这些软件设计原则：
SRP—单一责任原则
OCP—开关原则
LSP—Liskov替换原则
ISP—接口隔离原则
DIP—依赖倒置原则
上述这个原则的集合正好对应于缩略词SOLID。
下面的软件设计原则列表来自于《Head First Design Patterns》一书：
封装变化
多用组合少用继承
基于接口而不是基于实现编程
在交互的对象间努力实现松耦合
类应该为了扩展而开放，但是为了修改而关闭
依赖于抽象，而不要依赖于具体类
仅仅对你的朋友交谈
不调用我，我们会调用你
一个类应该仅有一个改变的理由
当然，上述原则之间也存在许多的重叠之处。例如，“单一责任”原则与后面的“一个类应该仅有一个改变的理由”这一原则是相一致的。然而，它们所强调的重点还是有所不同。更多的细节在此不便赘述。
所有这些设计原则的真正动机在于，努力构建出能够适应变化的软件。上述原则分别对于不同的原则进行相应的阐述，最终目的也不过是为了创建出可以经得起时间测试的软件。
6、 软件设计模式
软件设计模式描述的是应用软件设计原则所遵循的策略的问题。换句话说，一个软件设计原则是一个好的思想，而一个软件设计模式是你用于实现这种好的思想的工具。
软件设计模式的思想最初源于书籍《Design Patterns: Elements of Reusable Object-Oriented Software》。正是这本书为其它许多描述软件设计模式书的创作带去灵感。
例如，另一本书《The Head First Design Pattern》就以一种更易于理解的方式向人们介绍了GOF所着的书（即上面的那本《Design Patterns: Elements of Reusable Object-Oriented Software》）中所引入的设计模式。这本书中总共详细介绍了下列14种软件设计模式：
Strategy
Observer
Decorator
Factory
Singleton
Command
Adaptor
Fa?ade
Template
Iterator
Composite
State
Proxy
Compound
另一本在软件设计模式方面较有影响的书是Martin Fowler的《Patterns of Enterprise Application Architecture》。这本书还拥有一个公司网站，其中列举了本书中所介绍的模式。此网站的网址是：。
软件设计模式提供给你按照模式的方式构建你的代码，从而使之更富于适应未来的弹性修改。例如，当构建本文中的论坛应用程序时，我们就使用了一种名字为Repository的软件设计模式进行设计。Eric Evans，在他的着作《Domain-Driven Design》中这样描述Repository模式：
一个REPOSITORY把某种类型的所有对象描述为一个概念的集合(通常是模拟的)。其行为类似于一个集合，但是具有更细致的支持查询的能力。于是，符合相应类型的对象可以被添加或删除，而位于此REPOSITORY背后的系统则可以从数据库中添加或删除它们。
根据Evans的解释，Repository模式的一个主要的优点是，它能够帮助你实现“应用程序和域设计与存储技术，多种数据库策略，甚至是多个数据源之间的解耦。”换句话说，Repository模式能够使你的应用程序免于因数据库访问方式的不同而重新加以改变。
为了使我们的论坛应用程序从某一种特定的存储技术中独立出去，我们将在系统中引入上述Repository模式。因此，最终的此论坛应用程序的设计将能够支持我们可以在不同的数据访问技术（例如LINQ to SQL，Entity Framework或NHibernate）之间切换。
7、 测试驱动开发
我打算使用测试驱动开发原则构建本文中的MVC论坛应用程序。更具体地说是，在我编写任何应用程序代码之前，我将首先编写一个应用程序代码的单元测试。
测试驱动开发将会基于下列原因为你带来更高质量的代码：
(1)为你的代码编写测试能够提供给你一个适应于未来可能改变的安全网。
(2)为你的代码编写测试迫使你书写松耦合的代码。
(3)在正式书写你的代码前为你的代码编写测试将迫使你从一个用户的角度来观察自己书写的代码。
让我们更细致地分析上述每种特征的优点。
首先，单元测试提供你一个适应于未来可能改变的安全网。这是Michael Feathers在他的着作《Working Effectively with Legacy Code》一再强调的一个观点。事实上，他把遗留代码定义为“简单地编码而不进行测试”。
当你的应用程序代码被单元测试所覆盖时，你可以修改该代码而不必担心此改动会你的代码既有的功能。单元测试有助于使你的代码进行更安全的重构。如果你能够重构，那么，你可以使用软件设计模式修改你的代码，这将产生更好的适应未来修改的代码。
其次，遵循测试驱动开发将迫使你使用一种特定的方式书写代码。可测试的代码将趋于导致松耦合的代码。单元测试能够在各自孤立的代码单元中执行一个测试。为了构建你的应用程序以便使之可测试，你需要使用一种可孤立的组件方式来构建应用程序。
一个类与另一个类之间是松耦合的是指，当你改变第一个类时不必改变另一个类。测试驱动开发经常迫使你编写松耦合的代码，因为松耦合代码是经得起改变的。
最后，按照测试先行的方式书写代码将迫使你从一个用户的角度来观察自己书写的代码。通过首先编写测试的方式书写代码，会使你站在一个未来的有可能使用你的代码的开发者的角度进行工作。既然编写测试迫使你考虑另一个开发者(也许是未来的你自己)如何使用你的代码，那么，你最终编写的代码应该是设计得更好的代码。
8、 莫图眼前之利益 更宜立足于长远
使用测试驱动开发原则构建软件在软件开发之初要求开发者付出更多的努力。尽管编写测试需要花费一定的时间；然而，其思想是，最初构建单元测试所要求付出的努力将会在未来获得丰厚的回报。
存在两种方式可以使你成为一名开发者。你可以成长为一个牛仔，也有可能成长为一个工匠。一个牛仔能够立即开始编码。也就是说，一个牛仔可以以很快的速度构建一个软件应用程序。然而，作为一个牛仔，其问题在于软件必须要进行长期的维护。
一个工匠则是很有忍耐性的。一个工匠总会精雕细琢地开发一款软件。一个工匠总是非常仔细地构建单元测试，并使之涵盖一个应用程序中所有的代码。因此，一个工匠要花费更长的时间才能创建成功一款应用程序。然而，此应用程序在创建后，却是易于后期的维护—更易于修改错误且更易于把新特征添加到应用程序中。
9、 总结
总之，我们的最终目标是构建一个MVC论坛应用程序，此程序能够经得起长时间的测试。它应该是不仅现在良好地工作，还应该在未来继续工作—即使是当有人需要对该应用程序进行更改之时。
我想利用微软 MVC框架开发此论坛应用程序。原因在于，这个框架可以使我更容易地编写程序的测试代码。而另一方面， MVC框架本身就从设计之初提供了对测试驱动开发的最忠诚的支持。
Ⅲ 谈谈对MVC的认识
简单来说，MVC是一种流行的程序架构，获得C#、Java、PHP、Ruby等多种语言的支持。MVC是 模型（Model) 、视图(View)、控制器(Control) 的英文首字母的缩写，核心思想是：视图和用户交互 通过事件导致控制器改变 控制器改变导致模型改变 或者控制器同时改变两者 模型改变 导致视图改变 或者视图改变 潜在的从模型里面获得参数 来改变自己。
MVC（Model-View-Controller），即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。
视图(View)：代表用户交互界面，MVC设计模式对于视图的处理是限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。
模型(Model)：业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC的核心。
控制(Controller)：可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求，但是它却不做任何的数据处理。
它的优势在与：开发人员可以只关注整个结构中的其中某一层，可以很容易的用新的实现来替换原有层次的实现，可以降低层与层之间的依赖，有利于标准化，利于各层逻辑的复用