Discuz!NT的设计疑问(MVC)
请看过Discuz!NT 或者BBSMAX后台文件的继续往下看!
==============================================
传统的ASPX页面都对应到一个aspx.cs文件。比如Default.aspx对应Default.aspx.cs。绑定数据的时候都是在aspx页面中添加绑定控件并配置相关标签、数据库字段等。
而上面2种论坛程序都没有Default.aspx和Default.aspx.cs这种文件,仅仅有Html模板文件(不同页面定制不同的模板)和类文件
我猜测:应该是一个类A把网站的所有请求获取,然后根据请求的url找到对应模板文件(html)和处理对应数据的其他类B(还有很多类B2、B3、B4……)共同输出静态的html。但是一般涉及到文件IO的操作都会很慢,可能在读取模板的时候使用了缓存(如把常用的页面的模板缓存起来)
问题:
1.如果设计这个类A呢?
2.如果一个页面是显示查询结果,用表格的形式显示出来的(类似在Repeater中设计显示方式),模板文件中没有Repeater这种服务器,那么只能在类B中生成Table,这不是又背离了MVC逻辑与显示相分离么?(可能我上面的猜测是错误的才有这样的误解)
谢谢各位!
------解决方案--------------------
这就好比很多人以为用div+css不用table就是web标准了;
又有很多人以为搞个asp.netMVC就是MVC了;
又有很多人以为写几个class、泛型、反射、接口、工厂一齐上就是面向对象了;
模仿和学习别人的例子(比如petshop)并没有错,
可以用于生产之前先体会一下:
这样的架构是不是让代码生产离你还是个菜鸟的时候对编程的美好憧憬更近了一步呢?
还是你越来越觉得变成是一种痛苦呢?
discuz的代码架构是和他的生产手段相配套的,
尽管我们的生产手段和业务领域跟discuz都大相径庭,
但是从它的代码里我得到很多启发
------解决方案--------------------
我认为MVC设计模式,关键在于构建Model,Model就是MVC模式的灵魂,他包含了三层架构里面的 “实体规范层”、“行为规则层”、“数据访问层”;控制器(Controller)用来收集View提供的用户数据,传递给Model,同时返回Model处理后的数据给View。Model的设计可以参考三层架构的设计方法,将实体、行为规则(业务逻辑)和数据访问分开,在数据访问上可以应用ORM框架。三层架构同样可以应用ORM框架。个人认为三层架构和MVC都是很好的设计方法,目的都是降低系统的耦合性,提高重用率,提高系统的可维护性,可以根据喜好进行选择。
如何在三层架构和mvc之间进行取舍呢?或者说它们就和我所理解的一样,根据喜好选择,没有实质的优劣。同样是架构级别的,相同的地方在于他们都有一个表现层,但是他们不同的地方在于其他的两个层。在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层,这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model,但是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是以实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。
三层架构是最基本的项目分层结果,而MVC则是三层架构的一个变体,MVC是一种好的开发模式。首先你要明白MVC分别代表的是什么意思:
M 即Model(模型层),主要负责出来业务逻辑以及数据库的交互
V 即View(视图层),主要用于显示数据和提交数据
C 即Controller(控制器),主要是用作捕获请求并控制请求转发
三层:UI 界面层 BLL 业务逻辑层,DAL数据访问层,Model 实体层
MVC中的的M 不是三层中的Model(实体层),他其实包括三层中的 BLL,DAL,Model,这是非常要注意的,这也是他们之间的区别的关键所在。其优点如下: A、低耦合性; B、高重用性和可适用性; C、较低的生命周期成本;D、快速的部署;E、可维护性;F、有利于软件工程化管理。当然优点也有缺点,那就是内部结构复杂,不容易理解,文件数量大,管理难度自然也就大。
仔细研究了一下Microsoft ASP.NET MVC 1.0源代码,
并在两个网站项目中进行了具体应用。大致的总体技术框架结构如下:
基础结构: 全局接口、常量、公共工具类
数据实体:定义数据操作实体,主要用于业务逻辑层与数据访问层交互
业务模型层:定义具体业务需要的和View需要使用的模型类,用于业务逻辑层、View(视图层)、Controller(控制器)三方交互
数据访问层:修改RepositoryFactory,直接延用大体框架
业务逻辑层:提供业务处理服务,操作业务模型和数据实体
View(视图层):主要用于显示数据和提交数据,引用业务模型层
Controller(控制器):主要是用作捕获请求并控制请求转发,调用业务逻辑层,引用业务模型层
个人感觉对于预期扩展性很强的系统,采用这种架构还不错
MVC设计模式…
三层架构…
他们细分之后得到的是:View(UI)、BIZ(BLL)、DAO(DAL)、Entity(Model)、Controller
MVC把 BIZ(BLL)、DAO(DAL)、Model(Entity) 统一称之为 模型(MODEL),得到:View、Controller、模型(MODEL)
三层 在我使用中 暂未体会到控制器的存在,完全是:UI、DAO、BLL
他们相同的设计理念就是:把视图设计与数据持久化进行分离,从而降低耦合性,易于扩展,提高团队开发效率。