为什么不想办法让三层结构程序的编写与两层结构程序一样简单！(0分)

  • 主题发起人 主题发起人 blueboy
  • 开始时间 开始时间
B

blueboy

Unregistered / Unconfirmed
GUEST, unregistred user!
　　这个帖子同样不设分数，感兴趣的富翁不妨多说两句。
　　
　　做程序员其实也顶累的，学完了集中式的学C/S，学完了C/S学多层，学完了
多层......也不知以后还出什么新花样。
　　新技术很好，但能不能让我们不做得那么累？
　　我想，作为系统分析和设计人员，能不能做一些系统构架方面的设计，使得
程序员不用去学太多MIDAS的东东（最好是连李维的东东也不用学！），就可以
编写三层结构的程序，而且编程方法与C/S编写方法差不多？是不是有点矛盾？好
象不太可能吧？不知道哦，但这是一种需求。
　　
　　换一种说法来描述需求吧：事情是这样的，两年前你参加一个十人开发的小组，
开发出一套用户还算满意的软件，现在用户长大了，由原来的独立公司变成了集团
公司，你的程序也就得由C/S变成多层的，怎么办？这可是十个人开发将近一年的程
序哦，量那么大，不是说改就能改的，如果......就好了。


 
花半年去改吧^_^,三層也不是那麼難.
 
三层其实是一种很不错的改革，对于两层来说
它的好处实在是多了很多。
既然做了程序员就别说什么累了，只能勇往直前了。
 
半年？太吓人了吧，如果是这样，这个问题也就没有提出来的必要性了。改三层不难，但很烦琐啊。
我的理想是：原班人马，最多花两个星期改完。
 
娃娃的敬业精神让人敬佩，三层的技术也确实不错。但凡做事总有做的的方法，也就是做事的巧门吧。我们都希望做事效率更高一些，编程也不例外。
 
没有人对这个话题感兴趣了吗？
看来大家都在忙着编程序，没有人对系统构架感兴趣了，真不明白，难道那仅仅是系统设计员的事吗？[:)]
 
我想,从两层到三层,必然会经历短暂的痛苦,目前的技术应该是适应三层技术的一个过渡,
当大家都习惯三层思想的时候,而且技术规范也统一后,就不会感叹三层难做了......
 
　　谢谢trackboy回复。三层是潮流技术，大家迟早是要掌握，这点我想大家都不会有何想不通啦。
　　不过现在我想关注的是，象上面我所说的需求一样，要想把大量的c/s程序改成三层结构程序，
有没有简单易行的方法？我想如果设计得好应该是能够办得到的。如果一个一个地去改，那会很累
人，还会引入新的错误。
 
二层三层其实没多在的不一样，是你想得太难了。
 
　　1、编写一个通用的应用服务器程序，用以接收从Client传过来的SQL语句，执
行对数据库的操作，并把结果集返回给Client应用程序。
2、编写一个新的控件，该控件从TClientDataSet继承并增加一些属性,然后包
装成与TQuery具有同样属性和方法的控件TCQuery.
　　3、程序员在把C/S程序修改成三层结构的程序时，只要在原来程序中需要用到
TQuery的地方放上一个TCQuery控件，并把TCQuery控件名改成与原来TQuery控件名
一样的名字，原来TQuery控件或册除掉或改成别的名字。这样处理后原来程序不用
修改一句代码就可以改成三层结构的程序。省掉了要把每一个C/S程序拆分成Server
端和Client端的麻烦，并且不用把原程序中用TQeruy访问数据库的代码改成用ClientDataSet访问的代码，两者相加，可以大大减少修改工作量。我们的一个项目
原来做C/S开发时用了10人年，用这种方法只用两个星期就改成三层结构程序，效率
确实不错，所以拿出来想与大家讨论这个做法好不好。
　
 
　　从 Delphi 3 开始就用它的DCOM编三层结构的程序，当然也明白三层程序并不
难做。不过难与不难并不是我所关注的焦点。现在的问题是怎么用最简单的方法把
大量的C/S结构的程序改成三层结构的程序？
　　为了解决这个问题，当时我作了这样的设计：
　　1、编写一个通用的应用服务器程序，用以接收从Client传过来的SQL语句，执
行对数据库的操作，并把结果集返回给Client应用程序。
2、编写一个新的控件，该控件从TClientDataSet继承并增加一些属性,然后包
装成与TQuery具有同样属性和方法的控件TCQuery.
　　3、程序员在把C/S程序修改成三层结构的程序时，只要在原来程序中需要用到
TQuery的地方放上一个TCQuery控件，并把TCQuery控件名改成与原来TQuery控件名
一样的名字，原来TQuery控件或册除掉或改成别的名字。这样处理后原来程序不用
修改一句代码就可以改成三层结构的程序。省掉了要把每一个C/S程序拆分成Server
端和Client端的麻烦，并且不用把原程序中用TQeruy访问数据库的代码改成ClientDataSet
访问的代码，两者相加，可以大大减少修改工作量。我们的一个项目原来做C/S开发
时用了10人年，用这种方法只用两个星期就改成三层结构程序，效率确实不错，所
以拿出来想与大家讨论这个做法好不好。
　
 
其实也很容易！
如果两层下是基于BDE的，请使用MADIS下的DECOMConnection 与客户端通讯；
如果是基于ADO的，请使用SocketConnection，还要加入ADOConnection；
在做三层时应注意：
1、将两层中的企业规则移植到 COM中
2、制作接口（通讯规则和参数传递就是你自己的事情了，呵呵！）
3、别忘记了DataSetProvider
4、客户端请用 ClientDataSet
参照完整性检查就放在客户端吧，如果系统很大，应将这些事件处理过程剥离到子定义单元中，
这样代码风格简洁一些。
用5.0 开发吧，比较好。如果用ADO,别忘了打补丁，否则ADO一但在运行期激活失败，你就惨了。
Good Luck!
 
我想如果照上面各位的方法做的话，三层也没有什么意义了。
分布式编程最重要的要求是负载平衡及容错，以及系统的伸缩性。
它的基础应该是DCOM技术；
首先应该定义好系统应该有的接口及COM对象。
 
在通用的应用服务器里就不能解决负载平衡问题吗？系统的伸缩性是要在Client解决？
我想，用DELPHI来编写三层结构程序，肯定是要以DCOM或CORBA为基础，不管你做了怎么的
系统设计。如果是开发一套新系统，当然可以用新的方法来设计。现在的问题是用户不想花
太多的投资对原系统进行升级和改造，公司也不想投太多的人力物力去做旧业务。此种情形
下，如何用低成本去对旧系统进行改造而不是重写代码可能是一种比较合适的办法。
 
最好不改，老子曰：无为无不为
 
to: blueboy, 借你的宝地一用。　：）
看来大家春节也不休息，真是辛苦了。呵呵，给大家拜年了！！！
其实三层和两层的程序从编程角度来说，没有什么提高。可能也就是
多些属性需要设置。：）
但是正如大家所认识到的，将二层的程序改造成三层并不是让客户端
能够写ＳＱＬ就足够的，而是一种全新的程序架构。
开发方法和开发技术往往是相辅相成的。程序的开发方法现正在从
结构化－》面向对象－》面向过程过渡，而三层的程序架构（开发技术）
正是适应了这种开发方法。程序员的分工将随着程序分析系统化，
模块化而越来越细化，不同层次的程序员将编写不同层次的程序模块。
在三层开发中，其最终目标是将客户端程序实现为数据端采集器，其主要目的
是如何让不同层次的用户来使用，而不需要考虑存到什么库、什么表中。中间层
的开发人员则应当提供各种存储、查询等数据接口，并将主要精力集中在如何优化
算法中。这样才是真正意义上的三层。
三层程序的灵活性和可伸缩性从目前来讲，还是十分幼稚的。其灵活性往往是在
程序基本构建、测试完成以后，从代码重构的角度来进行优化；可伸缩性则是
在分担负载时，能够在不修改程序的前提下，通过增加中间层服务器的数量和配置
就能够满足业务的需求（当然，用户得既有心，也有力才行）。
至于三层程序的效率，目前只是一个美丽的谎言。任何三层程序的效率和两层程序
比起来都低的无法让人接受。但是三层程序的效率是体现在活字印刷和手写抄书的
不同。在灵活性和伸缩性的辅助下，效率往往才真的变得有意义。
以上是我开发三层程序这３年来的一些心得，欢迎大家评论。
 
技术成熟需要时间 高层技术人才毕竟没有我们想象那么多得用不完
 
据我所知，目前上海真正从事多层商业化软件开发的高手，掰掰手指头也数的过来。
看来，多层应用并不像大家想象的那么普遍，至少，我研究了几年，还没有吃透其精
髓，对多层应用的认识还只是停留在表面。
 
我看一个人5分钟就能搞定你的要求，
asta控件就支持从两层结构的软件source转换到三层结构的软件，他还提供一个
转换的wizard，5分钟肯定搞定。
asta在中间连接的服务器中优化了和数据库的连接，其实三层的思想是很好的
但在中国的软件开发能让你实现三层的机会吗，客户不知道自己的需求，对你做出来
的软件又不停的需要修改，你能把它的需求和业务逻辑抽象在中间层吗？？他们改动
最多的反而是客户端的界面
我认为c/s的结构压力主要集中在和服务器的连接上，保持数据库连接，一直占用
带宽和连接资源，网络和数据库服务器的压力就受不了。asta启用中间服务器连接
数据库，将所有c/s的连接抽象成标准的sql语句，用可靠的数据库事务完成，建立
和服务器的连接缓冲池，有效解决和服务器的连接数量和资源问题，采用包发送
方式，一次提交一定数量的数据给客户端，极大减轻网络的流量压力。我用它开发
的软件全部可以在internet,电话网上运行，效率和本地网相差无几，再用它本身
支持的在线升级功能维护客户端软件，你认为比midas三层有什么地方不好
 
好的系统结构设计是必要的，无论是两层或N层。
但如果都那么简单，我们就都没饭吃了，M$就全部搞定，M$可是要一桶浆糊的哦！
10clients的系统值得你用N层吗？N层的优势不在这里，另一方面，作为一个企业管理应用的
需要，应能够提供足够的允许业务管理的弹性，系统的稳定性和负载平衡，这些，在具体实现
上C/S与N层还是有差别的，所以，我觉得，不仅是一个SQL语句的问题。（这个问题容易处理）。
设想一下，如果你有一个应用，涉及100clients,100000数据记录，6个不同的部门的业务行为，
你会怎样做?(注意，用户通常会要求你，每个client,系统的响应时间被超过10s哦！)
 
您必须登录或注册才可回复。

Similar threads

Ray
[转]终于可以发布Delphi下收点OSGI精髓皮毛而设计的插件框架WisdomPluginFramework
回复
4
查看
5K
chlkuei
C
A
三层结构的简单问题？(300分)
回复
2
查看
169
ADV
A
L
三层结构程序开发，在中间层如何控制细表？(100分)
回复
9
查看
250
codesmall
C
A
MULTI-TIER三层结构数据库(100分)
回复
9
查看
222
aidac
A
B
三层结构的中间层安全问题？ (100分)
回复
5
查看
170
billrobin
B
后退
顶部