神马文学网B/S项目的开发心得
来源：百度文库 编辑：神马文学网 时间：2024/05/04 03:51:09
作者：陈缘
联系：luandao2000@gmail.com
网页：http://blog.csdn.net/luandao2000
最近做一个电信的项目，采用BS结构，工具用的VS.NET，语言C#。开发中磕磕碰碰的发生了很多问题，不过基本上都得到了比较好的解决。其实无论何种类型的开发，前期的架构设计都是需要认真的研究。我们的项目因为刚刚开始的时候基本上大家也都不怎么熟悉web上的开发，以前公司基本上都是做win32平台上的应用开发，所以对此类项目开发心里也没底。下面分几个方面讲讲我们在开发中出现的一些问题和解决方案
1、前期的调研和架构设计
事非经过不知难。以前以为自己的理解力和反应算比较好的，对于别人的思路基本上能在说的同时已经理解。这次和电信的一些业务口的人交流过程发现，即使说你再怎么聪明，对于业务没有一个全面基础的了解的前提下想去明白别人在讲什么，基本上不大可能。众所周知，电信企业作为典型的国有企业，虽然各种基础设备也算是属于科技性产品，但在管理上，国有企业的弊病基本上他都有。责任划分不清，部门间协差，人员散漫无章，会议繁多等等。此类问题给我们前期的调研造成了很多的困难，在调研上浪费的时间有2个多月。最后唯一的收获是：电信，我们的客户，基本上明白了他们需要一个能完成什么功能的系统。
在经过和n多部门多次开业务交流会的同时，我们项目组基本上也明白了业务上的很多细节，明白了客户具体的需求。
前期投入的人太少，前台受理上基本上开始就我一个人在做。在研究了客户现有情况和系统的情况下，我认为前台的业务受理口采用执行程序的方式会好一些，因为作为省一级的营业厅，业务量非常大。而WEB页面在很多方面不一定能满足这样的需求（前期对web开发了解不多）。而局方的看法是现有的系统CS模式已经过于陈旧，维护上存在很多问题，所以更希望采用BS模式来减少维护管理上的投入。当然作为一个行业类软件的研发，客户的建议基本上就是你的方向，最后项目采用BS模式开发。
因为对BS模式的开发并不熟悉，我开始查看各种资料，综合各种因素比较J2EE和ASP.NET的优略后决定采用ASP.NET来开发，当然最主要的原因是因为WIN32下的开发经历让我有信心相信掌握WEB类开发不会太难。于是开始研究VS.NET自带的开发实例，开始研究N层架构。
Duwamish和PetShop都是非常好的学习例子，事实上在开始的时候一直感觉为了一个简单的数据读写操作而设计好几层模块有点小题大做，后来随着理解上的逐步加深，才开始对分层的概念有了一些了解。比较了这两个例子的特点后，当然无所谓那个更好一点，只能说体现了微软两种不同的开发方法而已。
在看了孙亚民老师的两篇文章后深受启发，决定采用duwamish架构来设计整个项目。虽然网上有评论说：Duwamish的结构略显臃肿，资源消耗较大。但从业务对象的载体来说，使用类型化的DataSet来描述业务对象，虽然从资源的消耗来说确实有比轻量级的对象更大一些，但从功能分层的设计上来讲，个人觉得确实体现了分层的实质。即：各个模块各司其职。每层负责自己所关注的工作：业务逻辑层处理业务数据的处理，界面层提供输入输出，数据访问层完成实际的读写工作，表示层完成业务对象和数据库的映射。
层与层间依赖接口来交互，完成业务的处理。
采用的架构定下来后，项目组内部做了一些讨论。当然只是从很浮浅的层面上看看了duwamish的实现，然后基本上就定下来了。
2、开发中出现一些典型问题
A、业务对象的设计
在参考了孙老师的文章后，业务对象的设计基本上采用了类型化DataSet来设计。当然对于业务过程所需要的业务对象的确定是首先需要明确的，我开始研究原来的受理系统所实现的一些功能。
B、数据访问层各层的事务处理
C、层和层的接口设计
3、如何测试
先列个条目 改天上来继续写
联系：luandao2000@gmail.com
网页：http://blog.csdn.net/luandao2000
最近做一个电信的项目，采用BS结构，工具用的VS.NET，语言C#。开发中磕磕碰碰的发生了很多问题，不过基本上都得到了比较好的解决。其实无论何种类型的开发，前期的架构设计都是需要认真的研究。我们的项目因为刚刚开始的时候基本上大家也都不怎么熟悉web上的开发，以前公司基本上都是做win32平台上的应用开发，所以对此类项目开发心里也没底。下面分几个方面讲讲我们在开发中出现的一些问题和解决方案
1、前期的调研和架构设计
事非经过不知难。以前以为自己的理解力和反应算比较好的，对于别人的思路基本上能在说的同时已经理解。这次和电信的一些业务口的人交流过程发现，即使说你再怎么聪明，对于业务没有一个全面基础的了解的前提下想去明白别人在讲什么，基本上不大可能。众所周知，电信企业作为典型的国有企业，虽然各种基础设备也算是属于科技性产品，但在管理上，国有企业的弊病基本上他都有。责任划分不清，部门间协差，人员散漫无章，会议繁多等等。此类问题给我们前期的调研造成了很多的困难，在调研上浪费的时间有2个多月。最后唯一的收获是：电信，我们的客户，基本上明白了他们需要一个能完成什么功能的系统。
在经过和n多部门多次开业务交流会的同时，我们项目组基本上也明白了业务上的很多细节，明白了客户具体的需求。
前期投入的人太少，前台受理上基本上开始就我一个人在做。在研究了客户现有情况和系统的情况下，我认为前台的业务受理口采用执行程序的方式会好一些，因为作为省一级的营业厅，业务量非常大。而WEB页面在很多方面不一定能满足这样的需求（前期对web开发了解不多）。而局方的看法是现有的系统CS模式已经过于陈旧，维护上存在很多问题，所以更希望采用BS模式来减少维护管理上的投入。当然作为一个行业类软件的研发，客户的建议基本上就是你的方向，最后项目采用BS模式开发。
因为对BS模式的开发并不熟悉，我开始查看各种资料，综合各种因素比较J2EE和ASP.NET的优略后决定采用ASP.NET来开发，当然最主要的原因是因为WIN32下的开发经历让我有信心相信掌握WEB类开发不会太难。于是开始研究VS.NET自带的开发实例，开始研究N层架构。
Duwamish和PetShop都是非常好的学习例子，事实上在开始的时候一直感觉为了一个简单的数据读写操作而设计好几层模块有点小题大做，后来随着理解上的逐步加深，才开始对分层的概念有了一些了解。比较了这两个例子的特点后，当然无所谓那个更好一点，只能说体现了微软两种不同的开发方法而已。
在看了孙亚民老师的两篇文章后深受启发，决定采用duwamish架构来设计整个项目。虽然网上有评论说：Duwamish的结构略显臃肿，资源消耗较大。但从业务对象的载体来说，使用类型化的DataSet来描述业务对象，虽然从资源的消耗来说确实有比轻量级的对象更大一些，但从功能分层的设计上来讲，个人觉得确实体现了分层的实质。即：各个模块各司其职。每层负责自己所关注的工作：业务逻辑层处理业务数据的处理，界面层提供输入输出，数据访问层完成实际的读写工作，表示层完成业务对象和数据库的映射。
层与层间依赖接口来交互，完成业务的处理。
采用的架构定下来后，项目组内部做了一些讨论。当然只是从很浮浅的层面上看看了duwamish的实现，然后基本上就定下来了。
2、开发中出现一些典型问题
A、业务对象的设计
在参考了孙老师的文章后，业务对象的设计基本上采用了类型化DataSet来设计。当然对于业务过程所需要的业务对象的确定是首先需要明确的，我开始研究原来的受理系统所实现的一些功能。
B、数据访问层各层的事务处理
C、层和层的接口设计
3、如何测试
先列个条目 改天上来继续写
B/S项目的开发心得
★★MIS开发中C/S模式与B/S模式的结合策略
vitter‘s blog: [原创]windows下用openssh、ant、vss控制java项目的代码开发
在b/s开发中经常用到的javaScript技术 - keggle的专栏
哪位能说说c/s、b/s、多层结构的定义及优缺点？ Delphi / VCL组件开发及应用
策划开发一个项目 at onling’s blog
MOSS项目开发步骤 - 宋振乾's Blog - 博客园
关于网站(B/S开发中) cache应用（多图）
软件开发的项目管理
系统开发的项目规划
一个项目的开发流程
C/S与B/S的区别
项目心得
提升项目组的开发效率
项目的开发过程及成员组成
-旅游项目开发的商业策划
惠普公司的领导力开发项目
myeclipse应用程序开发系列之二：web项目的开发
myeclipse应用程序开发系列之二：web项目的开发
B/S下曲线的画法
最牛B的个性签名s
关于B/S和C/S架构的探析
关于B/S和C/S架构的探析
什么是基于B/S、c/s架构的系统设计