Web软件一般被从物理结构上分为3层:
[list]
[*]数据层,含数据库引擎及其操作代码,存取数据的地方。
[*]应用层,含Web应用服务程序(IIS、Apache),响应浏览器请求、执行Web程序。
[*]表现层,用户最后看到的网页。
[/list]
当然,如果你把数据库和应用服务安装在一台电脑上,然后在这台电脑上面用localhost访问,也是可以的 :D
开发Web软件,主要是通过设计、编码、测试来实现这3层的功能。
设计、实现的方法很多。但是,我要的,是一种最快速的实现方法:
[list]
[*]层与层之间的设计、开发不能脱节,一气呵成
[*]很容易修改,不要那种加了一个字段就得从数据库、实体、DAO、Business(还有用Facade的)、ASP.NET Form一路改过来的
[*][b]真的[/b]让我只用关注“业务”就可以了
[/list]
因为第2、第3个要求都是希望能够在开发中有一个可以“盯住”的基准。所以,首先要找到的,就是:以什么为基准?
基准的选择,大概有2种:
[list]
[*]对象驱动
[*]数据驱动
[/list]
选择对象驱动,对于快速Web开发,似乎不合适。
你可以说,做一个Order类来处理所有的订单,并且和Customer、Product类来聚合实现业务要求。但是,你无法写出:
(随别写的,可能编译不了: )
为什么?
因为分层。订单对象不能在客户端执行,服务器也不会等客户端确认了再往下运行后面的代码。
所以,如果做订单,一般得有操作订单数据库的类(对象)、对订单进行业务处理的类(对象)、显示订单内容的Form类(对象),来分别在各自的物理层上完成一个完整的订单功能。
所以,我选择了“数据驱动”。
不知道大家有没有这样的感觉:无论你如何的面向对象,心里始终有个声音在说:“数据库、数据库,表结构!”。至少,我是这样的。
动态Web站点,不能不想着数据库。无论你的类怎么设计,继承也好、聚合也好、范型也好,在内存里面跑完以后,还得存到数据库或者从数据库拿数据。
数据库变了,一切都变了。
想不变?也许可以,ORMapping的工具也许能够帮忙。但是,那个配置太烦了,只是把代码的耦合替换成了XML的耦合。相比之下,我更加喜欢代码的耦合,至少还可以通过开发工具方便的跳转来查找引用 :)
既然一直想着数据库,那么,就盯住数据库好了。
继续之前,先说明一下开发的核心:.[url=http://community.codesmithtools.com/blogs/tutorials/archive/2006/02/13/nettiers.aspx]netTiers[/url]
.netTiers本身的配置相对简单,链接里面的文档说明比较详细了。
但是,仅仅.netTiers是不够的,因为.netTiers只能生成框架,而且是基于数据库来生成框架(要的就是这个效果)。
所以需要一些配套的工具:
[img]http://jonyzhu.iteye.com/upload/attachment/34872/c1938bc6-2842-34d3-84a2-37170813d24d.jpg[/img]
关键的工具,就是:PowerDesigner 和 CodeSmith。
现在,我们要做的,就是:
[list]
[*]分析清楚业务流程
[*]提取名词、关系、约束,用PowerDesigner设计数据库的表。之所以用PowerDesigner设计表,主要是为了做数据库的版本控制。利用其“Generate Database”的功能可以生成数据库。而且对SQL Server 2000支持很好!设计的时候要注意:表间约束要规范,1个外键1个主键。
[*]生成数据库。
[*]用.netTiers来生成Web软件框架。这需要用到CodeSmith和微软企业库。
[*]用Visual Studio打开生成的框架,编译。
[*]用NUnit测试。
[*]直接用生成好的业务层、数据层、实体层的类来创建对象,开发具体的业务逻辑。
[/list]
一气呵成!
当数据库需要修改的时候,只要重复以上过程就可以了。.netTiers 一个好用的地方就是:可以跳过一些可能会在生成后被修改的文件,比如web.config。这样,重新生成的时候,就不会担心了。
RoR 里面 scaffold 和这个效果很像,所以我当初很有兴趣的研究了一下。不过,因为缺乏可视化的数据库建模工具,还是又转回 .netTiers 了。
[list]
[*]数据层,含数据库引擎及其操作代码,存取数据的地方。
[*]应用层,含Web应用服务程序(IIS、Apache),响应浏览器请求、执行Web程序。
[*]表现层,用户最后看到的网页。
[/list]
当然,如果你把数据库和应用服务安装在一台电脑上,然后在这台电脑上面用localhost访问,也是可以的 :D
开发Web软件,主要是通过设计、编码、测试来实现这3层的功能。
设计、实现的方法很多。但是,我要的,是一种最快速的实现方法:
[list]
[*]层与层之间的设计、开发不能脱节,一气呵成
[*]很容易修改,不要那种加了一个字段就得从数据库、实体、DAO、Business(还有用Facade的)、ASP.NET Form一路改过来的
[*][b]真的[/b]让我只用关注“业务”就可以了
[/list]
因为第2、第3个要求都是希望能够在开发中有一个可以“盯住”的基准。所以,首先要找到的,就是:以什么为基准?
基准的选择,大概有2种:
[list]
[*]对象驱动
[*]数据驱动
[/list]
选择对象驱动,对于快速Web开发,似乎不合适。
你可以说,做一个Order类来处理所有的订单,并且和Customer、Product类来聚合实现业务要求。但是,你无法写出:
// 生成订单
Order order = new Order(customer,product,qty);
// 请用户确认订单
if(order.Confirm()){
// 如果用户确认了订单,那么保存订单
order.Save();
}
// 无论用户是否确认订单,都在界面上显示订单的内容供进一步操作
order.Show();
(随别写的,可能编译不了: )
为什么?
因为分层。订单对象不能在客户端执行,服务器也不会等客户端确认了再往下运行后面的代码。
所以,如果做订单,一般得有操作订单数据库的类(对象)、对订单进行业务处理的类(对象)、显示订单内容的Form类(对象),来分别在各自的物理层上完成一个完整的订单功能。
所以,我选择了“数据驱动”。
不知道大家有没有这样的感觉:无论你如何的面向对象,心里始终有个声音在说:“数据库、数据库,表结构!”。至少,我是这样的。
动态Web站点,不能不想着数据库。无论你的类怎么设计,继承也好、聚合也好、范型也好,在内存里面跑完以后,还得存到数据库或者从数据库拿数据。
数据库变了,一切都变了。
想不变?也许可以,ORMapping的工具也许能够帮忙。但是,那个配置太烦了,只是把代码的耦合替换成了XML的耦合。相比之下,我更加喜欢代码的耦合,至少还可以通过开发工具方便的跳转来查找引用 :)
既然一直想着数据库,那么,就盯住数据库好了。
继续之前,先说明一下开发的核心:.[url=http://community.codesmithtools.com/blogs/tutorials/archive/2006/02/13/nettiers.aspx]netTiers[/url]
.netTiers本身的配置相对简单,链接里面的文档说明比较详细了。
但是,仅仅.netTiers是不够的,因为.netTiers只能生成框架,而且是基于数据库来生成框架(要的就是这个效果)。
所以需要一些配套的工具:
[img]http://jonyzhu.iteye.com/upload/attachment/34872/c1938bc6-2842-34d3-84a2-37170813d24d.jpg[/img]
关键的工具,就是:PowerDesigner 和 CodeSmith。
现在,我们要做的,就是:
[list]
[*]分析清楚业务流程
[*]提取名词、关系、约束,用PowerDesigner设计数据库的表。之所以用PowerDesigner设计表,主要是为了做数据库的版本控制。利用其“Generate Database”的功能可以生成数据库。而且对SQL Server 2000支持很好!设计的时候要注意:表间约束要规范,1个外键1个主键。
[*]生成数据库。
[*]用.netTiers来生成Web软件框架。这需要用到CodeSmith和微软企业库。
[*]用Visual Studio打开生成的框架,编译。
[*]用NUnit测试。
[*]直接用生成好的业务层、数据层、实体层的类来创建对象,开发具体的业务逻辑。
[/list]
一气呵成!
当数据库需要修改的时候,只要重复以上过程就可以了。.netTiers 一个好用的地方就是:可以跳过一些可能会在生成后被修改的文件,比如web.config。这样,重新生成的时候,就不会担心了。
RoR 里面 scaffold 和这个效果很像,所以我当初很有兴趣的研究了一下。不过,因为缺乏可视化的数据库建模工具,还是又转回 .netTiers 了。