那么我也来讲讲我对这两者的理解吧。
首先对这个题目，本身是存在问题的，“XX结构”与“XX模式”的区别？请问中国社会制度与美国人生活方式有什么区别？
这两者本身讲的是不同方向与角度的问题，在实际应用中他们的确存在一些相似的特点，在很多书籍中也没有深入讲解，以致于造成困惑，为了更好的理解他们，姑且来说说区别吧。
首先N层结构是一种软件抽象的层次结构，是对复杂软件的一种纵向切分，每一层次中完成同一类型的操作，以便将各种代码以其完成的使命作为依据来分割，以将低软件的复杂度，提高其可维护性。一般来说，层次之间是向下依赖的，下层代码未确定其接口（契约）前，上层代码是无法开发的，下层代码接口（契约）的变化将使上层的代码一起变化。三层结构是N层结构的一种，是人产在长时间使用中得出来的一种应用场合广泛的N层结构，被当作一种典型的软件层次结构而广为流传甚至写入教科书。
MVC模式是一种复合设计模式，一种在特定场合用于解决某种实际问题来得出的可以反复实践的解决方案。巧合的是他也有三个事物组成，于是乎人们就有了一种想当然的对应关系：展示层-View；业务逻辑层-Control；持久层-Model。首先MVC中的三个事物之间并不存在明显的层次结构，没有明显的向下依赖关系，相反的，View和Model往往是比较独立的，而Control是连接两者的桥梁，他们更像是横向的切分。这样一来就出现一个结果，MVC中每个块都是可以独立测试的，而三层结构中，上层模块的运行测试势必要提供下层代码或者提供相同接口的桩。相对来说，MVC复杂得多，但是结构更清晰，耦合性更低。
另外，MVC中每一块内部特别是Model内部经常被设计为多层的。在我认为的一个良好的MVC模式构建的结构中，Control是核心，小且较为稳定的，可以作为一个核心框架来提供，有扩展点，但基本上可以简单配置不需要任何代码就可以运行。而View则可能是一套或多种可选择的视图引擎，决定了软件展示给用于的界面，使用时的主要工作量在于扩展点以及根据需要而数量不同的视图模板。Model则是业务提供者，决定了软件提供的功能，其内部可能是一些普通的类或者是实现了某些接口的类，在这一块当中可能根据业务的不同而色彩缤纷，对于复杂的软件可能会分成很多层，如业务逻辑层、业务提供层、系统提供层、数据提供层、数据访问层等。
我经常用于比喻MVC的例子是小时候玩的那种卡带式游戏机，Control是主机，一般来说我买一个主机就行了，只要他不坏，他就能一直让我玩这一类的游戏。View则是电视机和游戏手柄，电视机可以独立工作，他不管输入的是电视信号、影碟机信号还是游戏机信号，他只管显示，而且他决定了我们看到的效果是怎么样的，如果我想要个尺寸更大的或者彩色的显示效果，我只需要买个相应的电视机就行了，手柄也是可以换的，要遥杆还是带震动的。Model则是游戏卡带，他绝定了我玩的是什么游戏，是魂斗罗还是超级玛莉，而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元，都根据游戏的需要而设计。
===================4/30补充＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
有朋友提到游戏主机提供的卡带插槽的接口，在设计中，有时也由Control提供一组接口，以用于Model或View的实现，这样就形成了依赖。一般来说这样设计也没有太大的问题，只是会提高模块间的耦合度，也会带来一些侵入性。为了更完美，可以不用接口来提供契约，可以用配置信息（或称元数据信息）+反射来提供契约，那么这个类接口就可以退化到只要符合CLS就可以了，也就是普通的类，就像现在的计算机接口广泛采用USB，无论是U盘、打印机、扫描仪或者是加密狗，他们都是普通的USB设备而已。
提到USB有一个题外话，模块的可插拔性设计甚至是热插拔设计，系统可以在不停止运行的情况下动态的挂载或移除模块，动态挂载模块需要系统能够自动发现新模块并根据自描述的信息进行自动配置，移除可能情况更复杂一点，需要“安全删除硬件”类似的功能。
在设计广泛重用的框架时会考虑多种情况以达到更大的适应性，一般项目中应用MVC模式可以较为随意。
框架、架构、模式、重构
有些概念，有人提到，一并说说吧。
框架很多，各种各样的，不同的平台，不同的语言，不同的功能。
现阶段的软件项目，几乎都会用到框架，何为框架，为什么要用框架。
所谓框架，是一种看得见的软件产品，是一种半成品。既然他是产品，他应该已经在那里了，如果你愿意，你可以使用他。就像一幢施工了一半，已经有梁有柱，有楼板、简单楼梯的五层楼房，只要你愿意，你可以爬楼梯锻炼身体。而他是半成品，说明他还不完整，需要对他进行填空。而这些空将决定“成品”是什么。刚才锻炼身体的楼房按照不同的布局和装饰可以成为写字楼，或者住宅。由于软件的可复制性，抽取出大部分楼房的共性，在此基础上加以相对少量的施工即可满足市场的需要，提高了软件的生产效率，此其一。
同样由于软件的可复制性，框架代码往往是较长时间的积累与实践测试，质量较高。上面说的那个楼房我保证每层楼高都相同，且结构可以抗8级地震，只要在这个结构基础上施工，不论多少人一起施工，房子也不会出这方面的问题，不管你懂不懂工程力学。因此提高了软件的质量，降低了开发难度与风险，加强团队开发的可能性，并降低了施工人员成本。此其二。
框架有其与生俱来的限制。还是那幢楼，如果你想在这个基础上建成国家体育场，想必也是没有什么可能的，如果蛮干，把大梁卸了，可能离新闻报道就不远了。所以选择框架要合适，使用框架也要遵循当初框架设计者的思路。此其三。
关于架构，这里讲的是软件架构。那是一种思想，你看不见。也没有一一对应的产品。他是实践中总结出的一种指导如何设计软件以达到某种要求的思路。
你要盖个一层两层小房，简单，来几根好点的木料，加几车砖，就行了，砖木结构。三到四层？砖混结构。五到十五层？钢混结构。十五层到四十层？全钢结构。四十层以上？那就复杂了，请教专家去。
架构思路是比较抽象的，他指明了在某种大体的场景下的大概的方向。在框架的设计中往往始终贯穿着一种或者几种架构思想。
模式呢？那是在某一范围内某种场景下为解决某种问题而可以重复实践的方案。高层建筑，用电梯。要房间明亮，弄个落地窗。这些使得我们在遇到某种场景下，不需要花大力气去思考，就可以较完美解决的方案。就像数学公式。
在框架内部，结构可能会十分复杂，中间也夹杂着太多的问题需要解决，所以在框架设计中，往往非常多的应用到模式。
事情很复杂，在开工之前没有必要将所有的细节全部考虑清楚。在施工过程中发现当前的结构中有一些不合理的地方。盖楼前没考虑用哪种门，先盖了再说吧，等开始装门的时候，发现每个房间的门都自己做，费工时，成本高，效果又不好。于是有个前辈说：不用这么麻烦，打个电话给XXX工厂，让他们提供某个系列的各种规格的门，送货上门，包安装还有保修，省心了。唔，重构就是在设计过程中对于软件中出现的臭味进行消除，使之符合某种设计模式的过程。