程
程云
Unregistered / Unconfirmed
GUEST, unregistred user!
千中元要在北京进行一次很有意义的技术型培训，想必大家都清楚了。
http://www.delphibbs.com/delphibbs/dispq.asp?LID=2206472 (如不清楚可见此连接)
很多人都对培训的讲师的水平能力和讲课内容提出疑问。
我有幸在10月20日下午，与其中一位讲师阿朱畅聊了一下午，
聊天记录整理出来了一部分，发在后面，
或可给一此人以帮助，或是用于了解讲解的水平和要讲的内容。
(注：阿朱，原名吕建伟，聊天记录中，有时会用“吕”或“伟”等字缩写)
《讲师闲谈录》(第一辑)
2003-10-20 15:12:15 阿朱()
如果你接手了一个大型应用系统的开发，你会首先想些什么问题？
2003-10-20 15:12:43 ※Angle※()
人手了，人手。
2003-10-20 15:13:09 阿朱()
要什么人？
2003-10-20 15:13:20 ※Angle※()
项目经理，
2003-10-20 15:13:40 ※Angle※()
要先找到这个人，然后，呵他这个人，会有能力帮你找到相关的人手的。：）
2003-10-20 15:13:54 阿朱()
如果你就是项目经理，你希望招些什么人？
如果你不是项目经理，你希望项目经理具有什么能力？
2003-10-20 15:18:00 程云()
阿朱，你不是来这里让别人提问你吗？
怎么只见你问别人呀
2003-10-20 15:18:51 阿朱()
因为没有人提问我，所以我先试探提问一下学员，看大家对某一主题感不感兴趣
2003-10-20 15:18:52 生命如歌()
项目经理要会对外联系，对内安排
2003-10-20 15:19:29 程云()
是呀，
刚上来，
(阿朱)是北京这次陪训的讲师阿朱，
谁想让他讲些什么，可在这里提出
2003-10-20 15:20:03 程云()
阿朱不知大家了解吗，
老在大富翁上出什么什么专集的那个，
去大富翁上搜索一下就可看到
2003-10-20 15:20:37 生命如歌()
老程，我到时想呀，手头三个项目再做，我出来不到
2003-10-20 15:22:15 阿朱()
继续啊，好啊，大家交流才能发现大家普遍想问的问题，否则我讲的学员不喜欢，那就白费钱财吗？
我讲的是大型企业架构开发，受众比较少，主要讲给想做架构师和开发项目经理的人听的，所以大富翁上的什么什么专集我怕是技巧集之类
2003-10-20 15:23:36 阿朱()
如果你接手了一个大型应用系统的开发，你会首先想些什么问题？
2003-10-20 15:24:13 生命如歌()
从纯技术方面说？
2003-10-20 15:24:19 ※Angle※()
我觉得应该考虑的，还是刚才那事，找人手。
2003-10-20 15:24:21 程云()
我首先要考虑是谁要用这个系统，
他们想要的是什么东西
2003-10-20 15:24:46 生命如歌()
我关心的是在客户方找一个人过来
2003-10-20 15:25:10 生命如歌()
大型系统没有客户业务精通人，参加，是有难度的
2003-10-20 15:25:31 阿朱()
然后呢？...
2003-10-20 15:26:03 生命如歌()
第二我会找一个好的项目经理，在这方面对行业比较熟悉，同时我找一个小MM，收集相关资料
2003-10-20 15:26:20 程云()
然后是确定软件的外面特征
和内部框架
2003-10-20 15:26:30 生命如歌()
资料不远全是本客户的，而是在本行业有共性的
2003-10-20 15:27:04 阿朱()
大型企业级应用开发前的常见难点，你们认为是什么？
2003-10-20 15:27:40 生命如歌()
规划结构
2003-10-20 15:28:04 程云()
对软件有个初步的描述应在找项目经理更早一步
2003-10-20 15:28:09 阿朱()
规划什么，结构主要关注什么？
2003-10-20 15:29:01 生命如歌()
规划，资源，时间，人，等
2003-10-20 15:29:27 阿朱()
在技术架构层面上的难点呢？
2003-10-20 15:30:09 生命如歌()
难点是在以前没有经验的架构上要做大系统，是有风险的
2003-10-20 15:30:55 阿朱()
你认为一个大系统的架构应该是什么样子呢？
你认为一个系统上的什么问题可以是架构平台可以解决的？
2003-10-20 15:30:56 生命如歌()
同时主要是系统设计人员对新系统的认知水平
2003-10-20 15:31:24 生命如歌()
大家都说说，我一个人打字打累
2003-10-20 15:31:44 生命如歌()
吕兄是不是有一个秘书在帮打字哟
2003-10-20 15:32:15 程云()
并行，集成，负载，7*24
2003-10-20 15:32:39 生命如歌()
可扩展
2003-10-20 15:32:56 程云()
好的系统都要可扩展
2003-10-20 15:33:08 阿朱()
你们遇到过下面这个问题吗？它可以用架构平台解决吗？
1功能不实用，需要加字段，改主键，改字段类型和长度，影响了已有系统，使已有功能出问题，新功能也出问题，整个系统问题多的就象立刻要爆炸。
2003-10-20 15:33:48 程云()
不好办
2003-10-20 15:33:49 生命如歌()
这种情况是否做了架构？
2003-10-20 15:34:35 生命如歌()
功能不实用的原因，是来自设计阶段或是根本的需求问题
2003-10-20 15:35:32 阿朱()
对，上一问题是架构平台可以解决的问题，不过对代码书写也是有要求的
我的意思时，系统无法调查到足够的需求，但必须要实现，你如何让系统以后修改起来好裁减扩展
2数据约束规则和数据逻辑关系，功能间逻辑，模块间关系老变，怎么有这些关系间的定制工具？
你们遇见过这个问题吗？
2003-10-20 15:35:32 程云()
需求总会改变，这已成定理，
再好的需求都会发生改变，
我们唯一能作的是想法让系统能适应这种改变
2003-10-20 15:36:10 生命如歌()
我认识是两向的
2003-10-20 15:36:56 阿朱()
第二个问题你们见过吗？是架构平台可以解决的吗？呵呵！
2003-10-20 15:36:58 生命如歌()
不能完全说用系统去面向需求，正是需求的千变万化，一个系统能不能有足够的成本去做
2003-10-20 15:37:15 生命如歌()
第二个问题是什么，我没看到
2003-10-20 15:37:26 阿朱()
数据约束规则和数据逻辑关系，功能间逻辑，模块间关系老变，怎么有这些关系间的定制工具？
你们遇见过这个问题吗？
2003-10-20 15:37:55 生命如歌()
我正在思考这个问题，
2003-10-20 15:38:22 生命如歌()
模块间关系老变，具体指什么
2003-10-20 15:39:14 阿朱()
我这里共收集了10个大型系统常见问题，他们是可以用架构平台解决的
模块间的关系指的是你没有做第一项业务时，这块业务不能做
2003-10-20 15:40:06 生命如歌()
你说的是类似程序中的状态控制 流程中的
2003-10-20 15:40:54 程云()
不错，
只阿朱给出的，就很值得一听了，
阿朱，你是那天讲课？？
2003-10-20 15:42:03 阿朱()
对，而且是细粒度的流程控制，不是现在的工作流，只控制到一个文档的人的流转，很好复杂业务，现在的工作流软件办不了，我指的是业务流程定制
2003-10-20 15:42:11 程云()
可千万别这个周未呀，
这个周未我考试BB
2003-10-20 15:42:34 阿朱()
大家发言呀
3由于不同的人，对于同一业务的功能和业务和可看见可修改的信息都不一样，如何安全控制到一个字段一个功能？
大家遇见过这个问题吗？
2003-10-20 15:42:52 程云()
有，我常遇到这个
2003-10-20 15:43:23 生命如歌()
业务流中常有其他要处理如资金，物，信息流，你怎么处理
2003-10-20 15:43:35 阿朱()
5明显的BUG都改了，但就是系统太复杂系统关联性太大，不知哪个系统在什么时候修改了数据，想录象和跟踪和回放
大家遇见过这个问题吗？
2003-10-20 15:44:11 生命如歌()
这些不是面向对象或组件系统开发要解决的吗
2003-10-20 15:44:25 程云()
业务流中有三个平行的流，
即物品流，票据流，资金流，
分别对应库房，业务和财务三个部门
2003-10-20 15:45:13 生命如歌()
程，我喜欢用信息流来换票据流
2003-10-20 15:45:22 程云()
5这个问题如存在的话，
那就是系统架构设计有问题，
完全可在架构设计时就避免错误的蔓延
2003-10-20 15:45:49 程云()
一样，一样的
我在很早时写过一篇文章
上面用的这个称呼，习惯了
2003-10-20 15:45:53 阿朱()
对呀，大型架构开发，需要一个平台，组件就成为单纯的业务组件，其他都让平台去管。
就象COM，只安心实现业务，事务，安全，定位，消息，池化都让中间件服务器做
2003-10-20 15:45:52 生命如歌()
如果是设计之前进行了比较好的构架，应该是可处理的
2003-10-20 15:46:23 阿朱()
我要讲的就是大型企业架构呀，所以我才测试一下大家对这些问题感不感兴趣？
2003-10-20 15:46:26 生命如歌()
吕，你说的是不是用组件去构架系统？
2003-10-20 15:46:47 程云()
很感 兴趣，
你可千万别这个周未讲，
不然，我可听不到了
2003-10-20 15:47:16 生命如歌()
吕，我不知你能讲到那个深度
2003-10-20 15:47:29 阿朱()
组件设计我倒不讲，主要是组件如何组合，这才是架构
7由于做了多家客户，功能增加了许多，源代码彼此都糅合在了一起，修改复杂，一发动全身，怎么才能自由组合和分离呢？
这个问题大家感不感兴趣？
2003-10-20 15:47:58 程云()
大型组件计划是由 Cnpack 的周劲羽来讲的，
2003-10-20 15:47:59 生命如歌()
接口要讲，不讲怎么组合
2003-10-20 15:48:34 阿朱()
我会照顾到大多数学员，中度深度，主要是做个思路和方法上的引导，让大家从此举一反三
2003-10-20 15:49:05 程云()
7的问题是源代码的版本控制问题
据说在第一天的课中，
周劲羽要专讲这个，
大型系统中的开发进度管理和控制中讲到
2003-10-20 15:49:20 阿朱()
关于组件，我曾经想写一本书，你可以看一下这张帖子
http://www.delphibbs.com/delphibbs/dispq.asp?LID=2237831
2003-10-20 15:49:31 生命如歌()
版本控问题说细一点
2003-10-20 15:50:22 阿朱()
噢，7的问题也不仅仅是版本控制问题，如果我写的代码都柔和在一起了，你想分都分不开了，想修改都下不了手，这就是代码架构问题
2003-10-20 15:50:31 程云()
这你得找周劲羽问
他对这个有很非富的经验，
他的Cnpack就是用这个，来进行网络合作开发的
2003-10-20 15:50:28 生命如歌()
你写了，我一定买
2003-10-20 15:51:23 阿朱()
因为在版本控制上，我也有比较多的经验，不是版本控制能解决的
2003-10-20 15:51:48 生命如歌()
你认为版本控制的最大问题是什么
2003-10-20 15:52:08 阿朱()
8系统间的协作接口很多，表太多，另一个系统人不熟悉我这个系统的表，要查询我这里的表，我多加了个标志位，他那里的查询语句就出了问题，报表老是调平了又乱了，稳定了一换程序又乱了再调
你们遇见过这个问题吗？
2003-10-20 15:53:06 程云()
以前常见，
作个好的通用报表工具
可基本解决
2003-10-20 15:53:42 阿朱()
报表是好设计，我知道，但就是数不平，问题在这里
2003-10-20 15:54:03 生命如歌()
一般说，对另一个系统不熟悉的人，是不应该直接去面对另一个系统的数据层的
2003-10-20 15:54:18 程云()
数不平是常见问题，
我以前作进销存平衡表时，
总与实际存在一些差别
2003-10-20 15:55:13 程云()
应该是浮点数的不精确计算产生的吧
2003-10-20 15:56:00 阿朱()
但没有好的组件件接口设计和系统间接口设计，老有人修改你的表，管也管不了，开发人太多，你无法控制，如果给他们一个东西，他们不用了解别人的表，他们就能做了他们的事情，他们当然不主动修改你的信息了，关键是这个
2003-10-20 15:56:18 阿朱()
不是计算精度的问题，是有人动你的数据
2003-10-20 15:56:33 生命如歌()
谁动了我的数据
2003-10-20 15:56:51 阿朱()
这个问题大家遇见过没有？
9报表的条件要求从这样查那样查，经常变，但报表SQL是些死的，怎么做这些查询条件设计工具？
2003-10-20 15:57:12 程云()
早就在思考的问题
2003-10-20 15:57:55 程云()
简单的报表是可作到通用化，
让用户自己去玩，
但复杂专业的，最终还是得让技术人员去设计
2003-10-20 15:58:31 阿朱()
6性能太低，怎么改都好象改善不了。改善到最后，原来是数据库表设计有问题，但已经不可改数据表了，否则一切都要推翻了。那如果从一开始就有一个好的数据库架构那多好
你们遇见过这个问题吗？
2003-10-20 15:58:36 生命如歌()
复杂的还不如用数据挖掘工具
2003-10-20 15:59:28 生命如歌()
6性能太低，如果需求的原因，我想不改数据库可能有难度
2003-10-20 15:59:37 程云()
数据挖掘专用工具
使用起来复杂，而且，价格也贵
2003-10-20 15:59:53 生命如歌()
不是说用到比较复杂的地方吗
2003-10-20 15:59:59 阿朱()
我刚才所说的是报表问题是：报表数据要求和格式都有了，但就是查询条件不同，就是入口不同，出口一个，你如何做？
2003-10-20 16:00:33 生命如歌()
是否让客户自己来组合SQL
2003-10-20 16:00:40 程云()
入口 问题复杂，不好统一
2003-10-20 16:00:44 阿朱()
数据挖掘我也作过 ，统计软件我也做过，你们先不要想到这个嘛，其实不太实用
2003-10-20 16:01:05 程云()
客户组合不出好的SQL，
有的要写非常复杂的SQL
2003-10-20 16:01:33 阿朱()
客户才不懂SQL呢，怎么办，呵呵
2003-10-20 16:01:35 生命如歌()
这种组合是否是无限的或是有限的组合
2003-10-20 16:01:44 阿朱()
需要报表查询条件设计工具
2003-10-20 16:01:53 生命如歌()
是
2003-10-20 16:02:07 程云()
当然，但如何构建这个？
2003-10-20 16:02:27 阿朱()
不会是无限的组合，是有限制的组合，有元数据在限制着呢？能看见什么条件组合，都有控制配置
2003-10-20 16:03:04 生命如歌()
如果是有限的组合，SQL设计器可以解决
2003-10-20 16:03:12 程云()
有限的是可以作到的，
万用的，只能是梦想了
2003-10-20 16:03:22 生命如歌()
关键是怎么组合
2003-10-20 16:03:43 阿朱()
没有万用的，生命如歌的问题才关键，呵呵
2003-10-20 16:03:57 程云()
SQL设计器也是不能给个数据库结构，
让客户去拖来拖去的玩
必须封装了这些问题
2003-10-20 16:04:17 生命如歌()
客户当然不能面向数据
2003-10-20 16:04:30 程云()
当然问题有万用的了，
这在若干年前就已认可了
除非作个人工智能来干这个，
这就是万用的了
2003-10-20 16:04:57 阿朱()
你们还想在大型应用架构上有什么问题？
2003-10-20 16:05:31 程云()
对架构设计的把握上，
什么样的架构才是好的
2003-10-20 16:05:59 生命如歌()
多种形式客户机，多种形式连接，多种分布数据同步
2003-10-20 16:06:30 阿朱()
生命如歌和程云再细说一下
2003-10-20 16:06:39 程云()
在架构设计时，如何才能避免
后期会出现技术上的盲点？
因为最初时是技术无关性，
但有时到了详细设计时，才发现技术上出现盲点
2003-10-20 16:07:01 阿朱()
比如说？...
2003-10-20 16:07:01 生命如歌()
程，说一个例
2003-10-20 16:07:04 程云()
(生命如歌)谈到了技术上了
2003-10-20 16:07:20 程云()
技术上的盲点是不可行性的问题
2003-10-20 16:07:33 生命如歌()
具体点
2003-10-20 16:07:53 生命如歌()
你现在的问题就容易产生盲点
2003-10-20 16:08:08 程云()
比如一个远程教学系统，
在最初时，并没有去考虑技术上的难点，
给出了，同时在线1000人，
和每个教室最多可有300人的设计
2003-10-20 16:08:09 阿朱()
对，我这个讲课也主要是偏向技术，在我的下一节课：程序员职业之路完全没有技术
2003-10-20 16:08:47 阿朱()
程云，然后呢？
2003-10-20 16:09:00 生命如歌()
然后系统肯定到不了那个多
2003-10-20 16:09:20 程云()
但在实现时，发现，
光以最好的技术传输语音，为8K带宽吧
这一个教室的人数
就至少需要 8*300=2.4M带宽
在技术上已出现解决不了的情况
2003-10-20 16:09:46 程云()
何况要传屏幕和视频，就更。。。。
2003-10-20 16:09:54 生命如歌()
这个就是我前面说的，在做新项目中的经验问题
2003-10-20 16:09:54 程云()
我只是举个例子，
2003-10-20 16:10:23 生命如歌()
我这种情况现在你去做肯定不会那些去写了吧
2003-10-20 16:10:44 生命如歌()
这是一个经验问题
2003-10-20 16:10:54 程云()
但需求的提出，并不是技术人员呀
而架构的设计，很多情况下，也不是由技术人员
去作，
2003-10-20 16:11:15 生命如歌()
我们一个项目要谈，我带一个人去，
2003-10-20 16:11:18 程云()
很多情况下都出现了这个问题，
常有对现有技术估计不足的情况
2003-10-20 16:11:23 生命如歌()
这个人肯定是系统设计人员
2003-10-20 16:12:23 生命如歌()
这个系统设计人员 要做的就是要解决这种系统大的限制问题，这个和项目报价等都有关，不一定是设计
2003-10-20 16:12:47 程云()
这里就要考虑到了，
一个项目对新技术的引入的问题，
有时，问题不象我刚举的这个例子这么明显。
对技术的估计在微弱之间，
即使先期已对这新技术作了例程上的准备
2003-10-20 16:12:59 程云()
但在项目中的应用，又是另一回事了
2003-10-20 16:13:25 生命如歌()
就是新技术的风险了，一般一个新项目不可能用很多新项目，
2003-10-20 16:13:28 程云()
再就是对大型项目进度上的管理和把握 问题
对它的工作量的估计和安排
2003-10-20 16:13:28 生命如歌()
新技术
2003-10-20 16:14:12 生命如歌()
如果是我们遇到没有做过的新项目，一般会新招人或委托专业公司去做，但以后肯定是自己做
2003-10-20 16:14:18 程云()
有时，即使有一个，
也会正在这个技术盲点的风险问题
有一个存在，这个项目已乎就已死定了，
问题就是如何更早的发现这个问题
2003-10-20 16:14:21 阿朱()
啊，这是我的一个要求，我一般不用新技术，但新架构也是一个子系统应用改进一些，不能完全新一代，否则风险很大
总监
精通业务 90%
项目经理
精通业务 100%
架构师
精通业务 80%
程序员
精通业务 70%
2003-10-20 16:14:53 ※Angle※()
这样的组合，很难找得到的。
2003-10-20 16:14:55 程云()
委托专业公司去做
那这个公司也要面临这个问题
2003-10-20 16:15:05 生命如歌()
这样的组合成本太高
2003-10-20 16:15:20 生命如歌()
除非你是做大系统，一般小公司受不了的
2003-10-20 16:15:45 程云()
是呀，这种组合不好弄，
而且，新技术的引入，是必然的，
如没有用新技术作过项目
那这种技术对你们来说，永远都是新技术了
2003-10-20 16:15:46 生命如歌()
专业公司的意思就是对某个方面有专功的
2003-10-20 16:16:25 程云()
大型系统是一个各方面都有的
综合系统，太专业的公司作不了的
2003-10-20 16:16:28 阿朱()
我这几个职位都做过，所以感触比较深，我一直工作在大型应用开发团队中，所以对小型开发确实了解不多，所以我讲的才是大型应用开发
2003-10-20 16:17:06 生命如歌()
专业的公司只做相关的一部分，并不是要理解全部架构
2003-10-20 16:17:19 程云()
这样，就又出现一个新问题
2003-10-20 16:18:20 程云()
大型系统，会分成几个部分，
分别来开发，
这样，在开发完成后，
组装的问题，
当然，真正的平滑对接是不可能的，
那如何避免其中的问题
2003-10-20 16:18:29 程云()
由其是多个公司合作开发的
2003-10-20 16:18:32 生命如歌()
程，就是现在面向对象开发推的是面向组合，而不是继承，有些专业的系统，应分给专业的做
2003-10-20 16:18:52 生命如歌()
专业公司就象一个组件，当然要有好的接口
2003-10-20 16:19:30 阿朱()
对，全部架构没有人全了解，我现在做总监，具体很细节的业务我也不太知道，但只要提出业务问题，我知道它怎么出来的，它应该怎么解决。我了解客户应用的历史，现状问题，未来发展趋势，这是我的层次该考虑的问题
2003-10-20 16:19:37 程云()
接口的定义，要求，
一但定义好，就不要改变它，
但正象需求一样，
它也总会变化的
2003-10-20 16:20:14 生命如歌()
说半天又说回来了，呵呵
2003-10-20 16:20:47 程云()
我现在就为初期的设计问题头疼，
如何能在初期，就定义好，
不变，或很少再发生变化的接口来
2003-10-20 16:20:52 生命如歌()
这正在我在想的问题，怎么去面对变化和重用
2003-10-20 16:21:44 程云()
我现在作的，只能是对接口进行
冗余的设计，
以应付有限可预料的变化
2003-10-20 16:22:13 阿朱()
噢，我主导了多个系统的设计，但都没有重用的现象。代码很快就会被修改，唯一的就是去适应变化
2003-10-20 16:22:26 飘尘()
兄弟们删谁了
2003-10-20 16:22:38 飘尘()
谁做过欠料,搞死了
2003-10-20 16:22:41 程云()
还是35个人，没有删吧
2003-10-20 16:23:02 程云()
重用的问题，
我也只作过一些简单的有限重用
2003-10-20 16:23:16 程云()
业务逻辑，很难被抽像
2003-10-20 16:23:41 生命如歌()
程，问个简单问题
2003-10-20 16:23:46 阿朱()
呵呵，不要想重用，主要的是去适应变化，而不是抽象
2003-10-20 16:25:20 阿朱()
生命如歌还有什么问题？
2003-10-20 16:25:35 程云()
是呀，他要问我什么？
2003-10-20 16:25:56 生命如歌()
业务逻辑是放在数据库中或是中间层
2003-10-20 16:26:17 程云()
放中间层是合理的，
只是把脚本放数据库中就是
2003-10-20 16:26:26 程云()
到时可去这里去读
2003-10-20 16:26:43 阿朱()
都有呀，干吗非要集中在某一层呢？每层都有它独特的优势和缺点，你们对这个也感兴趣？
2003-10-20 16:27:06 飘尘()
ANGLE删除,好不好呀
2003-10-20 16:27:15 阿朱()
我一直在犹豫讲不讲三层，因为这是一个很老的话题了
2003-10-20 16:27:24 生命如歌()
吕，这个问题是很多人关心的，可能你们高手已经解决
2003-10-20 16:27:31 程云()
客户端变化最快，和大，
放在中间层，最容易作到本系统的重用化
2003-10-20 16:27:54 生命如歌()
程，没得那么容易吧
2003-10-20 16:28:00 程云()
也就是被不同的客户端调用
在大型系统中，客户端可以有很多种，
或是类
2003-10-20 16:28:25 生命如歌()
如果数据库，客户端就不能调用？
2003-10-20 16:28:33 程云()
有呀，
我以前就是这么作的，
但把全部业务逻辑都放在中间层，
不太容易，只有选重要合适的了
2003-10-20 16:28:44 阿朱()
每层都有业务逻辑，只不过由于架构设计的好处，很多逻辑都，可以动态设计，改变时比写死了好的多了
2003-10-20 16:29:06 程云()
不是，不是，是业务对象，
不是单指业务的算法，和脚本，
2003-10-20 16:29:07 生命如歌()
好，就说放在中间
2003-10-20 16:29:21 生命如歌()
业务对象中有没有SQL语句 和规则
2003-10-20 16:29:48 程云()
这不一定吧，
SQL语句只是一种脚本，
有的业务对象，你可给它写自己的专有脚本
2003-10-20 16:29:58 程云()
这看你怎么设计了
2003-10-20 16:30:12 生命如歌()
你是怎么设计业务对象的
2003-10-20 16:30:56 程云()
完成单一的功能了，
同类的标准设计没有什么区别，
只是完成的是一个业务型的功能
2003-10-20 16:31:04 阿朱()
怎么回事？三层不是这样理解的！
2003-10-20 16:31:27 程云()
有时简单的，我会把业务逻辑直接写到类中
有时要在别地方记录脚本
2003-10-20 16:31:50 生命如歌()
程，是的，我还有放在数据库中的
2003-10-20 16:31:51 阿朱()
中间层是为解决什么问题产生的？
2003-10-20 16:32:07 生命如歌()
听吕老师讲
2003-10-20 16:32:19 程云()
三层就是把可重用的对象放在服务器上
提供给各个客户端进行调用，
客户可以是不同类的
2003-10-20 16:32:55 阿朱()
大家先思考一下
单机->C/S->c/s/s都是因为什么问题而出现了
大家先说说单机->C/S是为了解决什么问题？
2003-10-20 16:33:01 生命如歌()
不会是直接让客户调业务对象吗？或概念不一样
2003-10-20 16:33:26 生命如歌()
多客户 并发
2003-10-20 16:33:37 程云()
其中一个用处，
就是本系统中的对象重用
2003-10-20 16:33:58 生命如歌()
程，我问你的问题在这个，重用
2003-10-20 16:34:04 程云()
再就是可协调统一各不同的客户端，
或中间接力
2003-10-20 16:34:19 程云()
是的，中间层的确有这个用处，
我常这样合用它
2003-10-20 16:34:24 阿朱()
对，就是数据库不能每个客户端装一个，否则数据就不能共享了，
那三层呢？我暗示一下，呵呵
2003-10-20 16:34:25 生命如歌()
如果固定了一个对象的逻辑后，重用怎么做
2003-10-20 16:34:44 生命如歌()
更多的客户共享
2003-10-20 16:35:09 程云()
书上说，中间层的出现，
是业务逻辑改变后，
只要修改中间层就可
不用改每一个客户端
2003-10-20 16:35:36 生命如歌()
书上是这么说的，实际上也不一定是好做
2003-10-20 16:36:13 程云()
问题时，有时这种改变，
也会改变客户端，
但会有办法真的用到这一点
我尝试过
2003-10-20 16:36:46 阿朱()
啊，是由于业务更进一步复杂，其他系统开发的人根本无法知道另一个关联系统怎么回事，但要交互数据，怎么办，你让别人修改你的表数据去？
你把这个其他人调用的函数放哪里？放他们的每个机器上？
2003-10-20 16:36:51 生命如歌()
是的，有难度，如果中间的数据都改了，客户端不改，那只能用GRID
2003-10-20 16:37:22 程云()
中间层的协调和统一的功能吗
2003-10-20 16:37:33 生命如歌()
吕，这个用数据库的功能不是也有不少完成的
2003-10-20 16:37:51 阿朱()
数据库是为了其他人共享数据
中间层是为了其他人共享功能
2003-10-20 16:38:31 生命如歌()
同意，这种共享是让中间层组合关系更复杂
2003-10-20 16:38:41 生命如歌()
可能这也是你说讲组合的原因
2003-10-20 16:39:21 飘尘()
我QQ人太多,找不到,NND才开会.
2003-10-20 16:39:24 生命如歌()
数据库，按以前的说明也能实现功能
2003-10-20 16:39:43 程云()
我也找不到他了，
我这人太多了
2003-10-20 16:40:12 阿朱()
我过去参与设计的系统有26个产品，彼此关联，大约有800多张表，你让每个开发员都去了解关联的系统业务和表吗？
2003-10-20 16:40:57 生命如歌()
800表在一个库里？
2003-10-20 16:41:09 程云()
客户端并不去连接数据库
而只去联系中间层的接口就成了
2003-10-20 16:41:45 生命如歌()
但也要知道对口，和对象的组合实现功能
2003-10-20 16:41:49 阿朱()
如果你开发的是小型系统，一个人确实能了解了所有的表结构，但一个大型系统，每个系统都在发生变化，你如何理解，你的表在变，别人的表也在变，你关联的系统你如何知道，你按以前的做法如何实现？
2003-10-20 16:42:34 生命如歌()
这个问题能理解，
2003-10-20 16:42:58 生命如歌()
还是那个问题知道要在业务层来处理，但是怎么处理
2003-10-20 16:43:14 程云()
我是认为，先把表分类，
划分功能范围，
这样，所考虑的涉及的表都会很少，
完全可以全面了解表的结构和关连
2003-10-20 16:44:19 生命如歌()
以前的数据库的处理方式，是按以前程序设计方法面向过程的来配套的，
2003-10-20 16:44:44 生命如歌()
现在面向对象开发肯定会带来前台后台处理方式的改变
2003-10-20 16:44:54 阿朱()
再中间层的组件，一部分是我系统所有客户端公用的，一部分是给其他系统共享的。
每一层都可以有数据逻辑，在数据层也一样。SP也有插入更新删除，还有给其他系统使用的
2003-10-20 16:45:57 生命如歌()
吕，实际上，你在中间层还进行了分层，而不是一个层
2003-10-20 16:46:00 程云()
多层系统结构很有意思，
我在这些年的使用中，
发现，它还有很多潜力可挖
2003-10-20 16:46:16 生命如歌()
我现在就是在中间层再分层
2003-10-20 16:48:01 程云()
中间层分多少层都没关系，
只要看你的需要，
2003-10-20 16:48:21 阿朱()
面向对象，这个概念很吓人，千万不要拿出来吓人，呵呵
一个实体，如客户表，其实是三张物理表，一张概要信息表，供所有系统使用，一张二级常用信息，供某一些系统使用，还有一张三表，是供某个系统专用。这些表也不是一下子就全建立好的，而是随着业务的扩展不断加的，在设计时也没有想过，你想想我在业务变化时什么东西没有变
2003-10-20 16:49:23 阿朱()
我的每一层都还分层呀，那有每一物理层就一层啊
数据库还有物理表，VIEW，SP，JOB呢
2003-10-20 16:49:34 阿朱()
我的每一层都还分层呀，那有每一物理层就一层啊
数据库还有物理表，VIEW，SP，JOB呢
2003-10-20 16:50:07 生命如歌()
我说的，是现在很多做多层的，实际中间是一层包了全部
2003-10-20 16:50:10 阿朱()
生命如歌 程云 对三层还有什么问题？
本来这段可以在讲课中讲的，呵呵
2003-10-20 16:50:25 生命如歌()
呵呵，暂无
2003-10-20 16:50:31 程云()
问题不少，我下线整理一下再说
2003-10-20 16:50:43 FrameSniper()
阿朱，你说的很多概念我不太清楚啊
2003-10-20 16:50:47 飘尘()
三层分工怎么办
2003-10-20 16:50:50 阿朱()
那他们为什么要用三层？
2003-10-20 16:50:51 程云()
我先问一个我最关切的问题
就是负载均衡的问题
2003-10-20 16:51:08 阿朱()
程云 细化一些问题
2003-10-20 16:51:10 生命如歌()
因为时髦
2003-10-20 16:51:32 飘尘()
我们这里出了大问题了.c/s(ERP)都改死了F
2003-10-20 16:51:35 阿朱()
时髦也得了解这个时髦东西呀
2003-10-20 16:51:45 程云()
负载均衡 只是一个问题，
是如何作到，和哪何真正作到，
还有其中的实际意义
2003-10-20 16:52:03 阿朱()
难道大家不了解.Net 的优点和缺点就一头进去了？
2003-10-20 16:52:06 生命如歌()
吕，我还想知道数据同步
2003-10-20 16:52:12 程云()
多层系统是好东西，
我一发现它就入迷了
2003-10-20 16:52:42 阿朱()
你们过去对三层怎么理解的？
我讲课时可以添加进这段，呵呵
2003-10-20 16:52:49 生命如歌()
和业务逻辑的重用，是不是要改业务对象
2003-10-20 16:53:46 生命如歌()
大多对三层的理解就是看了李维的书，
2003-10-20 16:53:45 FrameSniper()
程云，你说的负载平衡是指什么
2003-10-20 16:54:18 生命如歌()
李维的书，如果不一本接一本也不好看懂，我也看过，感觉还是有问题
2003-10-20 16:54:28 阿朱()
业务对象肯定要改，但怎么改才好改，这样就是架构得问题了
重用，我的实战经历中发现重用的很少，因为业务在快速发生变化，没法重用
2003-10-20 16:54:38 程云()
三层的问题，
中间层所在的应用服务器，
如何让他进行负载均衡(多台)
2003-10-20 16:55:00 生命如歌()
COM+应该有这功能
2003-10-20 16:55:22 阿朱()
看李维的书？
李维是borland的产品经理呀，你知道意思的。
2003-10-20 16:55:31 生命如歌()
知道
2003-10-20 16:55:44 生命如歌()
这里不是还有些是产品经理呀
2003-10-20 16:55:50 阿朱()
application Center 2000可以解决负载均衡
2003-10-20 16:56:31 阿朱()
我曾经4台IBM Server做的集群
2003-10-20 16:56:45 程云()
有空再同你谈具体的问题，
我先下线了
一天了，一行代码没写呢
2003-10-20 16:56:46 生命如歌()
application Center 2000 要多少钱
2003-10-20 16:58:42 FrameSniper()
阿朱，你有自己的文章吗
2003-10-20 16:59:41 阿朱()
有是有，不过很多都作为了讲课材料，你可以查一下delphibbs，我曾经发表的
2003-10-20 17:00:09 FrameSniper()
好的，我现在是我们公司负责项目的，但有时候我有点思路很乱
2003-10-20 17:03:02 阿朱()
15岁开始开发，高中自学C和ASM解剖DOS，并且修改内核，瞎玩了
年龄，你见了我就知道了，呵呵
2003-10-20 17:03:45 FrameSniper()
呵呵，这个家伙，又开始在这里买弄了
2003-10-20 17:03:50 FrameSniper()
不过确实厉害
2003-10-20 17:03:58 FrameSniper()
牛人买弄清幽客源
2003-10-20 17:03:54 欢乐狗熊(228175978)
15岁开始开发，晕倒！高中自学C和ASM解剖DOS，并且修改内核，佩服！
2003-10-20 17:04:26 生命如歌()
现在主要的开发工具是什么
2003-10-20 17:04:27 FrameSniper()
我15岁还在那里肯吃肯吃的被初中毕业会考的东西呢
2003-10-20 17:05:42 阿朱()
我15岁玩的被我们家附近的所有游戏厅老板当作不让进的人，老一个钱币玩2个小时，不赚钱，呵呵
2003-10-20 17:17:59 阿朱()
大家对大型企业应用架构还有没有问题？
2003-10-20 17:18:18 FrameSniper()
我问题多多啊，只好1500个
2003-10-20 17:33:53 FrameSniper()
我以前做程序向来喜欢将具体业务过程中的参与方用类来进行封装，这样最后的结果就是多个模拟业务参与对象的类实体，然后具体的业务动作我模拟成类的方法，数据包含其中，所以我能想到的唯一把这种以前基于CS实现的结果转化为三层的方法就是将业务动作再进行重新归类，归结为更加抽象的中间层，不知道其他朋友如何看
2003-10-20 17:34:27 阿朱()
不要面向对象
2003-10-20 17:34:44 生命如歌()
面向组件?
2003-10-20 17:35:36 FrameSniper()
对，我以前是为了在软件结构中彻底实现面向对象才这么做的，刚开始感觉不错，但后来总是有中感觉，感觉效率很低，而且对具体的业务过程只是简单的代码模拟，而不是真正的再分析过程，所以一直想寻求一种提高结构的方式
2003-10-20 17:35:50 FrameSniper()
阿朱，你认为我应该如何做
2003-10-20 17:35:58 程云()
过度封装的问题吧
2003-10-20 17:35:59 FrameSniper()
我那种方式是不是很原始了
2003-10-20 17:36:18 FrameSniper()
过度封装？呵呵，这个概念好新颖
2003-10-20 17:36:27 FrameSniper()
两位给说说具体建议吧
2003-10-20 17:36:36 生命如歌()
FrameSniper，你这个也是一个过程，再去看模式，再简化
2003-10-20 17:36:39 程云()
过度封装的情况常见的
2003-10-20 17:37:23 FrameSniper()
你所说的模式是指什么？
2003-10-20 17:37:45 阿朱()
也不是面向组件。大型架构一搬从后台写起，把数据库能发挥的优势做完了，才下移到应用逻辑层来完成数据库不擅长的，直到应用逻辑层都不擅长的，如及时校验数据逻辑控制的，就写再客户端。
所以开发惯大型应用的，往往在服务器端关注，这也是J2EE一直关注在服务器端，客户端开发比较弱的原因
2003-10-20 17:37:59 程云()
见过有家公司，
一个孤立的过程和变量，
都要封装成一个对象来实现，
这就是典型的过度封装，
不但让系统过于复杂，
也严重降低系统效率
2003-10-20 17:39:03 阿朱()
不要过度考虑和过度设计，这是大型开发的关键陷阱，往往很多系统就是这样死的，如IBM的一款大型机系列就是这样
2003-10-20 17:39:16 FrameSniper()
阿朱，你的意思是开发大系统的时候眼光应该从最低层来看起，尤其在发挥整个系统功能的时候应该把功能着重点放在低层，然后在向上过滤？
2003-10-20 17:39:38 FrameSniper()
但我不知道为什么这样做呢，这样做有什么好处吗
2003-10-20 17:40:50 程云()
大型系统应着眼于系统架构，不应是底层
2003-10-20 17:40:53 生命如歌()
如果是把SQL放在数据库中用存贮过程，应该效率好，但还是不是要放在中间层中
2003-10-20 17:41:16 阿朱()
因为数据库好改，而其他各层都是二进制代码，不好在现场修改
2003-10-20 17:41:32 程云()
中间层可建立缓冲机制，
这样会完比数据库带来的好处好的多
在大型系统中
2003-10-20 17:41:33 阿朱()
大型系统应着眼于系统架构，不应是底层，程云说的对
2003-10-20 17:41:39 生命如歌()
但数据库维护也有难度，
2003-10-20 17:42:04 FrameSniper()
(阿朱) 17:41:16
因为数据库好改，而其他各层都是二进制代码，不好在现场修改
仅仅是因为这个原因？
2003-10-20 17:42:46 FrameSniper()
那还有其他方面吗，我不认为这个理由很充分
2003-10-20 17:43:28 FrameSniper()
另外中间层可建立缓冲机制----可以说的更详细点吗
为什么这样会给数据库带来更多的好处
2003-10-20 17:43:31 生命如歌()
有优点必有缺点，
2003-10-20 17:43:47 生命如歌()
我想数据库方面的开发主要是因为效率
2003-10-20 17:44:04 程云()
这是中间层的对象重用的问题了，
2003-10-20 17:44:22 FrameSniper()
什么意思，理解不了，可以大概说说思路吗
2003-10-20 17:44:36 生命如歌()
这是中间层的对象重用的问题了，我刚才就问了没有回答
2003-10-20 17:45:05 FrameSniper()
我有点不太明白你们说的中间层建立缓冲机制和对象重用的问题
2003-10-20 17:45:15 FrameSniper()
我有点不太明白你们说的中间层建立缓冲机制和对象重用的问题
2003-10-20 17:45:21 程云()
还有很多中间层的特性的问题，
很多功能用单层两层都是无法实现的，
而，多层就可以轻松作到，
这不是一两句说明白的，
多数是要自己亲身作一下，才可清楚的
2003-10-20 17:45:38 阿朱()
大型系统面临的最大的问题就是：定制耗用了大量时间。
架构就是为了解决稳定性，安全性，日志跟踪，封装数据提交复杂性，流程定制
架构需要数据库架构，中间层，客户端一起配合，不能是单独运作的
2003-10-20 17:47:01 FrameSniper()
阿朱，给推荐几本你认为比较适合偶这个水平的人看的软件架构的书吧
2003-10-20 17:47:02 程云()
对象重用，
不只是一个功能可供多个客户端同时使用，
也是读取的一组数据，可满足多个客户端同时使用上，
这就算是一个简单的数据缓冲了，
这样，每一个客户端不必都去读一次数据库
而只让中间层读取一次就可
2003-10-20 17:47:29 FrameSniper()
呵呵，类似DLL的调用机制
2003-10-20 17:47:42 FrameSniper()
一次载入，多次使用
2003-10-20 17:47:43 程云()
不不，比那强大的多，
2003-10-20 17:47:57 FrameSniper()
我知道，我就是作个比喻
2003-10-20 17:48:25 FrameSniper()
你的意思对象重用这种机制的实现必须依靠数据缓冲做辅助
2003-10-20 17:49:03 程云()
差不多吧，
还可建立对象回收机制，
这样，一个客户端在完成一个功能后，
释放了一个中间层对象，
但这个对象并不马上消失，
而是还存在一段时间，
如这时有另一个客户使用它，
那可不必再重建立，而可直接使用它就可
这叫对象缓冲和回收
2003-10-20 17:49:07 阿朱()
关于软件架构，一般都没有人写书，因为读者太少，而且能写此类书的人太少，还有就是这些都很宝贵一般不轻易写
所以我也没有看见，只是自己在多年设计开发实施中总结的
2003-10-20 17:49:49 程云()
有本清华出的《软件构架实践》一书
还凑合，可看一下
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
因为讲师工作都特别忙，
估计在这次培训之前，我也只能整理这一份《讲师闲谈录》了
但如果以后还有类似培训，我争取再继续出后期。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
http://www.delphibbs.com/delphibbs/dispq.asp?LID=2206472 (如不清楚可见此连接)
很多人都对培训的讲师的水平能力和讲课内容提出疑问。
我有幸在10月20日下午，与其中一位讲师阿朱畅聊了一下午，
聊天记录整理出来了一部分，发在后面，
或可给一此人以帮助，或是用于了解讲解的水平和要讲的内容。
(注：阿朱，原名吕建伟，聊天记录中，有时会用“吕”或“伟”等字缩写)
《讲师闲谈录》(第一辑)
2003-10-20 15:12:15 阿朱()
如果你接手了一个大型应用系统的开发，你会首先想些什么问题？
2003-10-20 15:12:43 ※Angle※()
人手了，人手。
2003-10-20 15:13:09 阿朱()
要什么人？
2003-10-20 15:13:20 ※Angle※()
项目经理，
2003-10-20 15:13:40 ※Angle※()
要先找到这个人，然后，呵他这个人，会有能力帮你找到相关的人手的。：）
2003-10-20 15:13:54 阿朱()
如果你就是项目经理，你希望招些什么人？
如果你不是项目经理，你希望项目经理具有什么能力？
2003-10-20 15:18:00 程云()
阿朱，你不是来这里让别人提问你吗？
怎么只见你问别人呀
2003-10-20 15:18:51 阿朱()
因为没有人提问我，所以我先试探提问一下学员，看大家对某一主题感不感兴趣
2003-10-20 15:18:52 生命如歌()
项目经理要会对外联系，对内安排
2003-10-20 15:19:29 程云()
是呀，
刚上来，
(阿朱)是北京这次陪训的讲师阿朱，
谁想让他讲些什么，可在这里提出
2003-10-20 15:20:03 程云()
阿朱不知大家了解吗，
老在大富翁上出什么什么专集的那个，
去大富翁上搜索一下就可看到
2003-10-20 15:20:37 生命如歌()
老程，我到时想呀，手头三个项目再做，我出来不到
2003-10-20 15:22:15 阿朱()
继续啊，好啊，大家交流才能发现大家普遍想问的问题，否则我讲的学员不喜欢，那就白费钱财吗？
我讲的是大型企业架构开发，受众比较少，主要讲给想做架构师和开发项目经理的人听的，所以大富翁上的什么什么专集我怕是技巧集之类
2003-10-20 15:23:36 阿朱()
如果你接手了一个大型应用系统的开发，你会首先想些什么问题？
2003-10-20 15:24:13 生命如歌()
从纯技术方面说？
2003-10-20 15:24:19 ※Angle※()
我觉得应该考虑的，还是刚才那事，找人手。
2003-10-20 15:24:21 程云()
我首先要考虑是谁要用这个系统，
他们想要的是什么东西
2003-10-20 15:24:46 生命如歌()
我关心的是在客户方找一个人过来
2003-10-20 15:25:10 生命如歌()
大型系统没有客户业务精通人，参加，是有难度的
2003-10-20 15:25:31 阿朱()
然后呢？...
2003-10-20 15:26:03 生命如歌()
第二我会找一个好的项目经理，在这方面对行业比较熟悉，同时我找一个小MM，收集相关资料
2003-10-20 15:26:20 程云()
然后是确定软件的外面特征
和内部框架
2003-10-20 15:26:30 生命如歌()
资料不远全是本客户的，而是在本行业有共性的
2003-10-20 15:27:04 阿朱()
大型企业级应用开发前的常见难点，你们认为是什么？
2003-10-20 15:27:40 生命如歌()
规划结构
2003-10-20 15:28:04 程云()
对软件有个初步的描述应在找项目经理更早一步
2003-10-20 15:28:09 阿朱()
规划什么，结构主要关注什么？
2003-10-20 15:29:01 生命如歌()
规划，资源，时间，人，等
2003-10-20 15:29:27 阿朱()
在技术架构层面上的难点呢？
2003-10-20 15:30:09 生命如歌()
难点是在以前没有经验的架构上要做大系统，是有风险的
2003-10-20 15:30:55 阿朱()
你认为一个大系统的架构应该是什么样子呢？
你认为一个系统上的什么问题可以是架构平台可以解决的？
2003-10-20 15:30:56 生命如歌()
同时主要是系统设计人员对新系统的认知水平
2003-10-20 15:31:24 生命如歌()
大家都说说，我一个人打字打累
2003-10-20 15:31:44 生命如歌()
吕兄是不是有一个秘书在帮打字哟
2003-10-20 15:32:15 程云()
并行，集成，负载，7*24
2003-10-20 15:32:39 生命如歌()
可扩展
2003-10-20 15:32:56 程云()
好的系统都要可扩展
2003-10-20 15:33:08 阿朱()
你们遇到过下面这个问题吗？它可以用架构平台解决吗？
1功能不实用，需要加字段，改主键，改字段类型和长度，影响了已有系统，使已有功能出问题，新功能也出问题，整个系统问题多的就象立刻要爆炸。
2003-10-20 15:33:48 程云()
不好办
2003-10-20 15:33:49 生命如歌()
这种情况是否做了架构？
2003-10-20 15:34:35 生命如歌()
功能不实用的原因，是来自设计阶段或是根本的需求问题
2003-10-20 15:35:32 阿朱()
对，上一问题是架构平台可以解决的问题，不过对代码书写也是有要求的
我的意思时，系统无法调查到足够的需求，但必须要实现，你如何让系统以后修改起来好裁减扩展
2数据约束规则和数据逻辑关系，功能间逻辑，模块间关系老变，怎么有这些关系间的定制工具？
你们遇见过这个问题吗？
2003-10-20 15:35:32 程云()
需求总会改变，这已成定理，
再好的需求都会发生改变，
我们唯一能作的是想法让系统能适应这种改变
2003-10-20 15:36:10 生命如歌()
我认识是两向的
2003-10-20 15:36:56 阿朱()
第二个问题你们见过吗？是架构平台可以解决的吗？呵呵！
2003-10-20 15:36:58 生命如歌()
不能完全说用系统去面向需求，正是需求的千变万化，一个系统能不能有足够的成本去做
2003-10-20 15:37:15 生命如歌()
第二个问题是什么，我没看到
2003-10-20 15:37:26 阿朱()
数据约束规则和数据逻辑关系，功能间逻辑，模块间关系老变，怎么有这些关系间的定制工具？
你们遇见过这个问题吗？
2003-10-20 15:37:55 生命如歌()
我正在思考这个问题，
2003-10-20 15:38:22 生命如歌()
模块间关系老变，具体指什么
2003-10-20 15:39:14 阿朱()
我这里共收集了10个大型系统常见问题，他们是可以用架构平台解决的
模块间的关系指的是你没有做第一项业务时，这块业务不能做
2003-10-20 15:40:06 生命如歌()
你说的是类似程序中的状态控制 流程中的
2003-10-20 15:40:54 程云()
不错，
只阿朱给出的，就很值得一听了，
阿朱，你是那天讲课？？
2003-10-20 15:42:03 阿朱()
对，而且是细粒度的流程控制，不是现在的工作流，只控制到一个文档的人的流转，很好复杂业务，现在的工作流软件办不了，我指的是业务流程定制
2003-10-20 15:42:11 程云()
可千万别这个周未呀，
这个周未我考试BB
2003-10-20 15:42:34 阿朱()
大家发言呀
3由于不同的人，对于同一业务的功能和业务和可看见可修改的信息都不一样，如何安全控制到一个字段一个功能？
大家遇见过这个问题吗？
2003-10-20 15:42:52 程云()
有，我常遇到这个
2003-10-20 15:43:23 生命如歌()
业务流中常有其他要处理如资金，物，信息流，你怎么处理
2003-10-20 15:43:35 阿朱()
5明显的BUG都改了，但就是系统太复杂系统关联性太大，不知哪个系统在什么时候修改了数据，想录象和跟踪和回放
大家遇见过这个问题吗？
2003-10-20 15:44:11 生命如歌()
这些不是面向对象或组件系统开发要解决的吗
2003-10-20 15:44:25 程云()
业务流中有三个平行的流，
即物品流，票据流，资金流，
分别对应库房，业务和财务三个部门
2003-10-20 15:45:13 生命如歌()
程，我喜欢用信息流来换票据流
2003-10-20 15:45:22 程云()
5这个问题如存在的话，
那就是系统架构设计有问题，
完全可在架构设计时就避免错误的蔓延
2003-10-20 15:45:49 程云()
一样，一样的
我在很早时写过一篇文章
上面用的这个称呼，习惯了
2003-10-20 15:45:53 阿朱()
对呀，大型架构开发，需要一个平台，组件就成为单纯的业务组件，其他都让平台去管。
就象COM，只安心实现业务，事务，安全，定位，消息，池化都让中间件服务器做
2003-10-20 15:45:52 生命如歌()
如果是设计之前进行了比较好的构架，应该是可处理的
2003-10-20 15:46:23 阿朱()
我要讲的就是大型企业架构呀，所以我才测试一下大家对这些问题感不感兴趣？
2003-10-20 15:46:26 生命如歌()
吕，你说的是不是用组件去构架系统？
2003-10-20 15:46:47 程云()
很感 兴趣，
你可千万别这个周未讲，
不然，我可听不到了
2003-10-20 15:47:16 生命如歌()
吕，我不知你能讲到那个深度
2003-10-20 15:47:29 阿朱()
组件设计我倒不讲，主要是组件如何组合，这才是架构
7由于做了多家客户，功能增加了许多，源代码彼此都糅合在了一起，修改复杂，一发动全身，怎么才能自由组合和分离呢？
这个问题大家感不感兴趣？
2003-10-20 15:47:58 程云()
大型组件计划是由 Cnpack 的周劲羽来讲的，
2003-10-20 15:47:59 生命如歌()
接口要讲，不讲怎么组合
2003-10-20 15:48:34 阿朱()
我会照顾到大多数学员，中度深度，主要是做个思路和方法上的引导，让大家从此举一反三
2003-10-20 15:49:05 程云()
7的问题是源代码的版本控制问题
据说在第一天的课中，
周劲羽要专讲这个，
大型系统中的开发进度管理和控制中讲到
2003-10-20 15:49:20 阿朱()
关于组件，我曾经想写一本书，你可以看一下这张帖子
http://www.delphibbs.com/delphibbs/dispq.asp?LID=2237831
2003-10-20 15:49:31 生命如歌()
版本控问题说细一点
2003-10-20 15:50:22 阿朱()
噢，7的问题也不仅仅是版本控制问题，如果我写的代码都柔和在一起了，你想分都分不开了，想修改都下不了手，这就是代码架构问题
2003-10-20 15:50:31 程云()
这你得找周劲羽问
他对这个有很非富的经验，
他的Cnpack就是用这个，来进行网络合作开发的
2003-10-20 15:50:28 生命如歌()
你写了，我一定买
2003-10-20 15:51:23 阿朱()
因为在版本控制上，我也有比较多的经验，不是版本控制能解决的
2003-10-20 15:51:48 生命如歌()
你认为版本控制的最大问题是什么
2003-10-20 15:52:08 阿朱()
8系统间的协作接口很多，表太多，另一个系统人不熟悉我这个系统的表，要查询我这里的表，我多加了个标志位，他那里的查询语句就出了问题，报表老是调平了又乱了，稳定了一换程序又乱了再调
你们遇见过这个问题吗？
2003-10-20 15:53:06 程云()
以前常见，
作个好的通用报表工具
可基本解决
2003-10-20 15:53:42 阿朱()
报表是好设计，我知道，但就是数不平，问题在这里
2003-10-20 15:54:03 生命如歌()
一般说，对另一个系统不熟悉的人，是不应该直接去面对另一个系统的数据层的
2003-10-20 15:54:18 程云()
数不平是常见问题，
我以前作进销存平衡表时，
总与实际存在一些差别
2003-10-20 15:55:13 程云()
应该是浮点数的不精确计算产生的吧
2003-10-20 15:56:00 阿朱()
但没有好的组件件接口设计和系统间接口设计，老有人修改你的表，管也管不了，开发人太多，你无法控制，如果给他们一个东西，他们不用了解别人的表，他们就能做了他们的事情，他们当然不主动修改你的信息了，关键是这个
2003-10-20 15:56:18 阿朱()
不是计算精度的问题，是有人动你的数据
2003-10-20 15:56:33 生命如歌()
谁动了我的数据
2003-10-20 15:56:51 阿朱()
这个问题大家遇见过没有？
9报表的条件要求从这样查那样查，经常变，但报表SQL是些死的，怎么做这些查询条件设计工具？
2003-10-20 15:57:12 程云()
早就在思考的问题
2003-10-20 15:57:55 程云()
简单的报表是可作到通用化，
让用户自己去玩，
但复杂专业的，最终还是得让技术人员去设计
2003-10-20 15:58:31 阿朱()
6性能太低，怎么改都好象改善不了。改善到最后，原来是数据库表设计有问题，但已经不可改数据表了，否则一切都要推翻了。那如果从一开始就有一个好的数据库架构那多好
你们遇见过这个问题吗？
2003-10-20 15:58:36 生命如歌()
复杂的还不如用数据挖掘工具
2003-10-20 15:59:28 生命如歌()
6性能太低，如果需求的原因，我想不改数据库可能有难度
2003-10-20 15:59:37 程云()
数据挖掘专用工具
使用起来复杂，而且，价格也贵
2003-10-20 15:59:53 生命如歌()
不是说用到比较复杂的地方吗
2003-10-20 15:59:59 阿朱()
我刚才所说的是报表问题是：报表数据要求和格式都有了，但就是查询条件不同，就是入口不同，出口一个，你如何做？
2003-10-20 16:00:33 生命如歌()
是否让客户自己来组合SQL
2003-10-20 16:00:40 程云()
入口 问题复杂，不好统一
2003-10-20 16:00:44 阿朱()
数据挖掘我也作过 ，统计软件我也做过，你们先不要想到这个嘛，其实不太实用
2003-10-20 16:01:05 程云()
客户组合不出好的SQL，
有的要写非常复杂的SQL
2003-10-20 16:01:33 阿朱()
客户才不懂SQL呢，怎么办，呵呵
2003-10-20 16:01:35 生命如歌()
这种组合是否是无限的或是有限的组合
2003-10-20 16:01:44 阿朱()
需要报表查询条件设计工具
2003-10-20 16:01:53 生命如歌()
是
2003-10-20 16:02:07 程云()
当然，但如何构建这个？
2003-10-20 16:02:27 阿朱()
不会是无限的组合，是有限制的组合，有元数据在限制着呢？能看见什么条件组合，都有控制配置
2003-10-20 16:03:04 生命如歌()
如果是有限的组合，SQL设计器可以解决
2003-10-20 16:03:12 程云()
有限的是可以作到的，
万用的，只能是梦想了
2003-10-20 16:03:22 生命如歌()
关键是怎么组合
2003-10-20 16:03:43 阿朱()
没有万用的，生命如歌的问题才关键，呵呵
2003-10-20 16:03:57 程云()
SQL设计器也是不能给个数据库结构，
让客户去拖来拖去的玩
必须封装了这些问题
2003-10-20 16:04:17 生命如歌()
客户当然不能面向数据
2003-10-20 16:04:30 程云()
当然问题有万用的了，
这在若干年前就已认可了
除非作个人工智能来干这个，
这就是万用的了
2003-10-20 16:04:57 阿朱()
你们还想在大型应用架构上有什么问题？
2003-10-20 16:05:31 程云()
对架构设计的把握上，
什么样的架构才是好的
2003-10-20 16:05:59 生命如歌()
多种形式客户机，多种形式连接，多种分布数据同步
2003-10-20 16:06:30 阿朱()
生命如歌和程云再细说一下
2003-10-20 16:06:39 程云()
在架构设计时，如何才能避免
后期会出现技术上的盲点？
因为最初时是技术无关性，
但有时到了详细设计时，才发现技术上出现盲点
2003-10-20 16:07:01 阿朱()
比如说？...
2003-10-20 16:07:01 生命如歌()
程，说一个例
2003-10-20 16:07:04 程云()
(生命如歌)谈到了技术上了
2003-10-20 16:07:20 程云()
技术上的盲点是不可行性的问题
2003-10-20 16:07:33 生命如歌()
具体点
2003-10-20 16:07:53 生命如歌()
你现在的问题就容易产生盲点
2003-10-20 16:08:08 程云()
比如一个远程教学系统，
在最初时，并没有去考虑技术上的难点，
给出了，同时在线1000人，
和每个教室最多可有300人的设计
2003-10-20 16:08:09 阿朱()
对，我这个讲课也主要是偏向技术，在我的下一节课：程序员职业之路完全没有技术
2003-10-20 16:08:47 阿朱()
程云，然后呢？
2003-10-20 16:09:00 生命如歌()
然后系统肯定到不了那个多
2003-10-20 16:09:20 程云()
但在实现时，发现，
光以最好的技术传输语音，为8K带宽吧
这一个教室的人数
就至少需要 8*300=2.4M带宽
在技术上已出现解决不了的情况
2003-10-20 16:09:46 程云()
何况要传屏幕和视频，就更。。。。
2003-10-20 16:09:54 生命如歌()
这个就是我前面说的，在做新项目中的经验问题
2003-10-20 16:09:54 程云()
我只是举个例子，
2003-10-20 16:10:23 生命如歌()
我这种情况现在你去做肯定不会那些去写了吧
2003-10-20 16:10:44 生命如歌()
这是一个经验问题
2003-10-20 16:10:54 程云()
但需求的提出，并不是技术人员呀
而架构的设计，很多情况下，也不是由技术人员
去作，
2003-10-20 16:11:15 生命如歌()
我们一个项目要谈，我带一个人去，
2003-10-20 16:11:18 程云()
很多情况下都出现了这个问题，
常有对现有技术估计不足的情况
2003-10-20 16:11:23 生命如歌()
这个人肯定是系统设计人员
2003-10-20 16:12:23 生命如歌()
这个系统设计人员 要做的就是要解决这种系统大的限制问题，这个和项目报价等都有关，不一定是设计
2003-10-20 16:12:47 程云()
这里就要考虑到了，
一个项目对新技术的引入的问题，
有时，问题不象我刚举的这个例子这么明显。
对技术的估计在微弱之间，
即使先期已对这新技术作了例程上的准备
2003-10-20 16:12:59 程云()
但在项目中的应用，又是另一回事了
2003-10-20 16:13:25 生命如歌()
就是新技术的风险了，一般一个新项目不可能用很多新项目，
2003-10-20 16:13:28 程云()
再就是对大型项目进度上的管理和把握 问题
对它的工作量的估计和安排
2003-10-20 16:13:28 生命如歌()
新技术
2003-10-20 16:14:12 生命如歌()
如果是我们遇到没有做过的新项目，一般会新招人或委托专业公司去做，但以后肯定是自己做
2003-10-20 16:14:18 程云()
有时，即使有一个，
也会正在这个技术盲点的风险问题
有一个存在，这个项目已乎就已死定了，
问题就是如何更早的发现这个问题
2003-10-20 16:14:21 阿朱()
啊，这是我的一个要求，我一般不用新技术，但新架构也是一个子系统应用改进一些，不能完全新一代，否则风险很大
总监
精通业务 90%
项目经理
精通业务 100%
架构师
精通业务 80%
程序员
精通业务 70%
2003-10-20 16:14:53 ※Angle※()
这样的组合，很难找得到的。
2003-10-20 16:14:55 程云()
委托专业公司去做
那这个公司也要面临这个问题
2003-10-20 16:15:05 生命如歌()
这样的组合成本太高
2003-10-20 16:15:20 生命如歌()
除非你是做大系统，一般小公司受不了的
2003-10-20 16:15:45 程云()
是呀，这种组合不好弄，
而且，新技术的引入，是必然的，
如没有用新技术作过项目
那这种技术对你们来说，永远都是新技术了
2003-10-20 16:15:46 生命如歌()
专业公司的意思就是对某个方面有专功的
2003-10-20 16:16:25 程云()
大型系统是一个各方面都有的
综合系统，太专业的公司作不了的
2003-10-20 16:16:28 阿朱()
我这几个职位都做过，所以感触比较深，我一直工作在大型应用开发团队中，所以对小型开发确实了解不多，所以我讲的才是大型应用开发
2003-10-20 16:17:06 生命如歌()
专业的公司只做相关的一部分，并不是要理解全部架构
2003-10-20 16:17:19 程云()
这样，就又出现一个新问题
2003-10-20 16:18:20 程云()
大型系统，会分成几个部分，
分别来开发，
这样，在开发完成后，
组装的问题，
当然，真正的平滑对接是不可能的，
那如何避免其中的问题
2003-10-20 16:18:29 程云()
由其是多个公司合作开发的
2003-10-20 16:18:32 生命如歌()
程，就是现在面向对象开发推的是面向组合，而不是继承，有些专业的系统，应分给专业的做
2003-10-20 16:18:52 生命如歌()
专业公司就象一个组件，当然要有好的接口
2003-10-20 16:19:30 阿朱()
对，全部架构没有人全了解，我现在做总监，具体很细节的业务我也不太知道，但只要提出业务问题，我知道它怎么出来的，它应该怎么解决。我了解客户应用的历史，现状问题，未来发展趋势，这是我的层次该考虑的问题
2003-10-20 16:19:37 程云()
接口的定义，要求，
一但定义好，就不要改变它，
但正象需求一样，
它也总会变化的
2003-10-20 16:20:14 生命如歌()
说半天又说回来了，呵呵
2003-10-20 16:20:47 程云()
我现在就为初期的设计问题头疼，
如何能在初期，就定义好，
不变，或很少再发生变化的接口来
2003-10-20 16:20:52 生命如歌()
这正在我在想的问题，怎么去面对变化和重用
2003-10-20 16:21:44 程云()
我现在作的，只能是对接口进行
冗余的设计，
以应付有限可预料的变化
2003-10-20 16:22:13 阿朱()
噢，我主导了多个系统的设计，但都没有重用的现象。代码很快就会被修改，唯一的就是去适应变化
2003-10-20 16:22:26 飘尘()
兄弟们删谁了
2003-10-20 16:22:38 飘尘()
谁做过欠料,搞死了
2003-10-20 16:22:41 程云()
还是35个人，没有删吧
2003-10-20 16:23:02 程云()
重用的问题，
我也只作过一些简单的有限重用
2003-10-20 16:23:16 程云()
业务逻辑，很难被抽像
2003-10-20 16:23:41 生命如歌()
程，问个简单问题
2003-10-20 16:23:46 阿朱()
呵呵，不要想重用，主要的是去适应变化，而不是抽象
2003-10-20 16:25:20 阿朱()
生命如歌还有什么问题？
2003-10-20 16:25:35 程云()
是呀，他要问我什么？
2003-10-20 16:25:56 生命如歌()
业务逻辑是放在数据库中或是中间层
2003-10-20 16:26:17 程云()
放中间层是合理的，
只是把脚本放数据库中就是
2003-10-20 16:26:26 程云()
到时可去这里去读
2003-10-20 16:26:43 阿朱()
都有呀，干吗非要集中在某一层呢？每层都有它独特的优势和缺点，你们对这个也感兴趣？
2003-10-20 16:27:06 飘尘()
ANGLE删除,好不好呀
2003-10-20 16:27:15 阿朱()
我一直在犹豫讲不讲三层，因为这是一个很老的话题了
2003-10-20 16:27:24 生命如歌()
吕，这个问题是很多人关心的，可能你们高手已经解决
2003-10-20 16:27:31 程云()
客户端变化最快，和大，
放在中间层，最容易作到本系统的重用化
2003-10-20 16:27:54 生命如歌()
程，没得那么容易吧
2003-10-20 16:28:00 程云()
也就是被不同的客户端调用
在大型系统中，客户端可以有很多种，
或是类
2003-10-20 16:28:25 生命如歌()
如果数据库，客户端就不能调用？
2003-10-20 16:28:33 程云()
有呀，
我以前就是这么作的，
但把全部业务逻辑都放在中间层，
不太容易，只有选重要合适的了
2003-10-20 16:28:44 阿朱()
每层都有业务逻辑，只不过由于架构设计的好处，很多逻辑都，可以动态设计，改变时比写死了好的多了
2003-10-20 16:29:06 程云()
不是，不是，是业务对象，
不是单指业务的算法，和脚本，
2003-10-20 16:29:07 生命如歌()
好，就说放在中间
2003-10-20 16:29:21 生命如歌()
业务对象中有没有SQL语句 和规则
2003-10-20 16:29:48 程云()
这不一定吧，
SQL语句只是一种脚本，
有的业务对象，你可给它写自己的专有脚本
2003-10-20 16:29:58 程云()
这看你怎么设计了
2003-10-20 16:30:12 生命如歌()
你是怎么设计业务对象的
2003-10-20 16:30:56 程云()
完成单一的功能了，
同类的标准设计没有什么区别，
只是完成的是一个业务型的功能
2003-10-20 16:31:04 阿朱()
怎么回事？三层不是这样理解的！
2003-10-20 16:31:27 程云()
有时简单的，我会把业务逻辑直接写到类中
有时要在别地方记录脚本
2003-10-20 16:31:50 生命如歌()
程，是的，我还有放在数据库中的
2003-10-20 16:31:51 阿朱()
中间层是为解决什么问题产生的？
2003-10-20 16:32:07 生命如歌()
听吕老师讲
2003-10-20 16:32:19 程云()
三层就是把可重用的对象放在服务器上
提供给各个客户端进行调用，
客户可以是不同类的
2003-10-20 16:32:55 阿朱()
大家先思考一下
单机->C/S->c/s/s都是因为什么问题而出现了
大家先说说单机->C/S是为了解决什么问题？
2003-10-20 16:33:01 生命如歌()
不会是直接让客户调业务对象吗？或概念不一样
2003-10-20 16:33:26 生命如歌()
多客户 并发
2003-10-20 16:33:37 程云()
其中一个用处，
就是本系统中的对象重用
2003-10-20 16:33:58 生命如歌()
程，我问你的问题在这个，重用
2003-10-20 16:34:04 程云()
再就是可协调统一各不同的客户端，
或中间接力
2003-10-20 16:34:19 程云()
是的，中间层的确有这个用处，
我常这样合用它
2003-10-20 16:34:24 阿朱()
对，就是数据库不能每个客户端装一个，否则数据就不能共享了，
那三层呢？我暗示一下，呵呵
2003-10-20 16:34:25 生命如歌()
如果固定了一个对象的逻辑后，重用怎么做
2003-10-20 16:34:44 生命如歌()
更多的客户共享
2003-10-20 16:35:09 程云()
书上说，中间层的出现，
是业务逻辑改变后，
只要修改中间层就可
不用改每一个客户端
2003-10-20 16:35:36 生命如歌()
书上是这么说的，实际上也不一定是好做
2003-10-20 16:36:13 程云()
问题时，有时这种改变，
也会改变客户端，
但会有办法真的用到这一点
我尝试过
2003-10-20 16:36:46 阿朱()
啊，是由于业务更进一步复杂，其他系统开发的人根本无法知道另一个关联系统怎么回事，但要交互数据，怎么办，你让别人修改你的表数据去？
你把这个其他人调用的函数放哪里？放他们的每个机器上？
2003-10-20 16:36:51 生命如歌()
是的，有难度，如果中间的数据都改了，客户端不改，那只能用GRID
2003-10-20 16:37:22 程云()
中间层的协调和统一的功能吗
2003-10-20 16:37:33 生命如歌()
吕，这个用数据库的功能不是也有不少完成的
2003-10-20 16:37:51 阿朱()
数据库是为了其他人共享数据
中间层是为了其他人共享功能
2003-10-20 16:38:31 生命如歌()
同意，这种共享是让中间层组合关系更复杂
2003-10-20 16:38:41 生命如歌()
可能这也是你说讲组合的原因
2003-10-20 16:39:21 飘尘()
我QQ人太多,找不到,NND才开会.
2003-10-20 16:39:24 生命如歌()
数据库，按以前的说明也能实现功能
2003-10-20 16:39:43 程云()
我也找不到他了，
我这人太多了
2003-10-20 16:40:12 阿朱()
我过去参与设计的系统有26个产品，彼此关联，大约有800多张表，你让每个开发员都去了解关联的系统业务和表吗？
2003-10-20 16:40:57 生命如歌()
800表在一个库里？
2003-10-20 16:41:09 程云()
客户端并不去连接数据库
而只去联系中间层的接口就成了
2003-10-20 16:41:45 生命如歌()
但也要知道对口，和对象的组合实现功能
2003-10-20 16:41:49 阿朱()
如果你开发的是小型系统，一个人确实能了解了所有的表结构，但一个大型系统，每个系统都在发生变化，你如何理解，你的表在变，别人的表也在变，你关联的系统你如何知道，你按以前的做法如何实现？
2003-10-20 16:42:34 生命如歌()
这个问题能理解，
2003-10-20 16:42:58 生命如歌()
还是那个问题知道要在业务层来处理，但是怎么处理
2003-10-20 16:43:14 程云()
我是认为，先把表分类，
划分功能范围，
这样，所考虑的涉及的表都会很少，
完全可以全面了解表的结构和关连
2003-10-20 16:44:19 生命如歌()
以前的数据库的处理方式，是按以前程序设计方法面向过程的来配套的，
2003-10-20 16:44:44 生命如歌()
现在面向对象开发肯定会带来前台后台处理方式的改变
2003-10-20 16:44:54 阿朱()
再中间层的组件，一部分是我系统所有客户端公用的，一部分是给其他系统共享的。
每一层都可以有数据逻辑，在数据层也一样。SP也有插入更新删除，还有给其他系统使用的
2003-10-20 16:45:57 生命如歌()
吕，实际上，你在中间层还进行了分层，而不是一个层
2003-10-20 16:46:00 程云()
多层系统结构很有意思，
我在这些年的使用中，
发现，它还有很多潜力可挖
2003-10-20 16:46:16 生命如歌()
我现在就是在中间层再分层
2003-10-20 16:48:01 程云()
中间层分多少层都没关系，
只要看你的需要，
2003-10-20 16:48:21 阿朱()
面向对象，这个概念很吓人，千万不要拿出来吓人，呵呵
一个实体，如客户表，其实是三张物理表，一张概要信息表，供所有系统使用，一张二级常用信息，供某一些系统使用，还有一张三表，是供某个系统专用。这些表也不是一下子就全建立好的，而是随着业务的扩展不断加的，在设计时也没有想过，你想想我在业务变化时什么东西没有变
2003-10-20 16:49:23 阿朱()
我的每一层都还分层呀，那有每一物理层就一层啊
数据库还有物理表，VIEW，SP，JOB呢
2003-10-20 16:49:34 阿朱()
我的每一层都还分层呀，那有每一物理层就一层啊
数据库还有物理表，VIEW，SP，JOB呢
2003-10-20 16:50:07 生命如歌()
我说的，是现在很多做多层的，实际中间是一层包了全部
2003-10-20 16:50:10 阿朱()
生命如歌 程云 对三层还有什么问题？
本来这段可以在讲课中讲的，呵呵
2003-10-20 16:50:25 生命如歌()
呵呵，暂无
2003-10-20 16:50:31 程云()
问题不少，我下线整理一下再说
2003-10-20 16:50:43 FrameSniper()
阿朱，你说的很多概念我不太清楚啊
2003-10-20 16:50:47 飘尘()
三层分工怎么办
2003-10-20 16:50:50 阿朱()
那他们为什么要用三层？
2003-10-20 16:50:51 程云()
我先问一个我最关切的问题
就是负载均衡的问题
2003-10-20 16:51:08 阿朱()
程云 细化一些问题
2003-10-20 16:51:10 生命如歌()
因为时髦
2003-10-20 16:51:32 飘尘()
我们这里出了大问题了.c/s(ERP)都改死了F
2003-10-20 16:51:35 阿朱()
时髦也得了解这个时髦东西呀
2003-10-20 16:51:45 程云()
负载均衡 只是一个问题，
是如何作到，和哪何真正作到，
还有其中的实际意义
2003-10-20 16:52:03 阿朱()
难道大家不了解.Net 的优点和缺点就一头进去了？
2003-10-20 16:52:06 生命如歌()
吕，我还想知道数据同步
2003-10-20 16:52:12 程云()
多层系统是好东西，
我一发现它就入迷了
2003-10-20 16:52:42 阿朱()
你们过去对三层怎么理解的？
我讲课时可以添加进这段，呵呵
2003-10-20 16:52:49 生命如歌()
和业务逻辑的重用，是不是要改业务对象
2003-10-20 16:53:46 生命如歌()
大多对三层的理解就是看了李维的书，
2003-10-20 16:53:45 FrameSniper()
程云，你说的负载平衡是指什么
2003-10-20 16:54:18 生命如歌()
李维的书，如果不一本接一本也不好看懂，我也看过，感觉还是有问题
2003-10-20 16:54:28 阿朱()
业务对象肯定要改，但怎么改才好改，这样就是架构得问题了
重用，我的实战经历中发现重用的很少，因为业务在快速发生变化，没法重用
2003-10-20 16:54:38 程云()
三层的问题，
中间层所在的应用服务器，
如何让他进行负载均衡(多台)
2003-10-20 16:55:00 生命如歌()
COM+应该有这功能
2003-10-20 16:55:22 阿朱()
看李维的书？
李维是borland的产品经理呀，你知道意思的。
2003-10-20 16:55:31 生命如歌()
知道
2003-10-20 16:55:44 生命如歌()
这里不是还有些是产品经理呀
2003-10-20 16:55:50 阿朱()
application Center 2000可以解决负载均衡
2003-10-20 16:56:31 阿朱()
我曾经4台IBM Server做的集群
2003-10-20 16:56:45 程云()
有空再同你谈具体的问题，
我先下线了
一天了，一行代码没写呢
2003-10-20 16:56:46 生命如歌()
application Center 2000 要多少钱
2003-10-20 16:58:42 FrameSniper()
阿朱，你有自己的文章吗
2003-10-20 16:59:41 阿朱()
有是有，不过很多都作为了讲课材料，你可以查一下delphibbs，我曾经发表的
2003-10-20 17:00:09 FrameSniper()
好的，我现在是我们公司负责项目的，但有时候我有点思路很乱
2003-10-20 17:03:02 阿朱()
15岁开始开发，高中自学C和ASM解剖DOS，并且修改内核，瞎玩了
年龄，你见了我就知道了，呵呵
2003-10-20 17:03:45 FrameSniper()
呵呵，这个家伙，又开始在这里买弄了
2003-10-20 17:03:50 FrameSniper()
不过确实厉害
2003-10-20 17:03:58 FrameSniper()
牛人买弄清幽客源
2003-10-20 17:03:54 欢乐狗熊(228175978)
15岁开始开发，晕倒！高中自学C和ASM解剖DOS，并且修改内核，佩服！
2003-10-20 17:04:26 生命如歌()
现在主要的开发工具是什么
2003-10-20 17:04:27 FrameSniper()
我15岁还在那里肯吃肯吃的被初中毕业会考的东西呢
2003-10-20 17:05:42 阿朱()
我15岁玩的被我们家附近的所有游戏厅老板当作不让进的人，老一个钱币玩2个小时，不赚钱，呵呵
2003-10-20 17:17:59 阿朱()
大家对大型企业应用架构还有没有问题？
2003-10-20 17:18:18 FrameSniper()
我问题多多啊，只好1500个
2003-10-20 17:33:53 FrameSniper()
我以前做程序向来喜欢将具体业务过程中的参与方用类来进行封装，这样最后的结果就是多个模拟业务参与对象的类实体，然后具体的业务动作我模拟成类的方法，数据包含其中，所以我能想到的唯一把这种以前基于CS实现的结果转化为三层的方法就是将业务动作再进行重新归类，归结为更加抽象的中间层，不知道其他朋友如何看
2003-10-20 17:34:27 阿朱()
不要面向对象
2003-10-20 17:34:44 生命如歌()
面向组件?
2003-10-20 17:35:36 FrameSniper()
对，我以前是为了在软件结构中彻底实现面向对象才这么做的，刚开始感觉不错，但后来总是有中感觉，感觉效率很低，而且对具体的业务过程只是简单的代码模拟，而不是真正的再分析过程，所以一直想寻求一种提高结构的方式
2003-10-20 17:35:50 FrameSniper()
阿朱，你认为我应该如何做
2003-10-20 17:35:58 程云()
过度封装的问题吧
2003-10-20 17:35:59 FrameSniper()
我那种方式是不是很原始了
2003-10-20 17:36:18 FrameSniper()
过度封装？呵呵，这个概念好新颖
2003-10-20 17:36:27 FrameSniper()
两位给说说具体建议吧
2003-10-20 17:36:36 生命如歌()
FrameSniper，你这个也是一个过程，再去看模式，再简化
2003-10-20 17:36:39 程云()
过度封装的情况常见的
2003-10-20 17:37:23 FrameSniper()
你所说的模式是指什么？
2003-10-20 17:37:45 阿朱()
也不是面向组件。大型架构一搬从后台写起，把数据库能发挥的优势做完了，才下移到应用逻辑层来完成数据库不擅长的，直到应用逻辑层都不擅长的，如及时校验数据逻辑控制的，就写再客户端。
所以开发惯大型应用的，往往在服务器端关注，这也是J2EE一直关注在服务器端，客户端开发比较弱的原因
2003-10-20 17:37:59 程云()
见过有家公司，
一个孤立的过程和变量，
都要封装成一个对象来实现，
这就是典型的过度封装，
不但让系统过于复杂，
也严重降低系统效率
2003-10-20 17:39:03 阿朱()
不要过度考虑和过度设计，这是大型开发的关键陷阱，往往很多系统就是这样死的，如IBM的一款大型机系列就是这样
2003-10-20 17:39:16 FrameSniper()
阿朱，你的意思是开发大系统的时候眼光应该从最低层来看起，尤其在发挥整个系统功能的时候应该把功能着重点放在低层，然后在向上过滤？
2003-10-20 17:39:38 FrameSniper()
但我不知道为什么这样做呢，这样做有什么好处吗
2003-10-20 17:40:50 程云()
大型系统应着眼于系统架构，不应是底层
2003-10-20 17:40:53 生命如歌()
如果是把SQL放在数据库中用存贮过程，应该效率好，但还是不是要放在中间层中
2003-10-20 17:41:16 阿朱()
因为数据库好改，而其他各层都是二进制代码，不好在现场修改
2003-10-20 17:41:32 程云()
中间层可建立缓冲机制，
这样会完比数据库带来的好处好的多
在大型系统中
2003-10-20 17:41:33 阿朱()
大型系统应着眼于系统架构，不应是底层，程云说的对
2003-10-20 17:41:39 生命如歌()
但数据库维护也有难度，
2003-10-20 17:42:04 FrameSniper()
(阿朱) 17:41:16
因为数据库好改，而其他各层都是二进制代码，不好在现场修改
仅仅是因为这个原因？
2003-10-20 17:42:46 FrameSniper()
那还有其他方面吗，我不认为这个理由很充分
2003-10-20 17:43:28 FrameSniper()
另外中间层可建立缓冲机制----可以说的更详细点吗
为什么这样会给数据库带来更多的好处
2003-10-20 17:43:31 生命如歌()
有优点必有缺点，
2003-10-20 17:43:47 生命如歌()
我想数据库方面的开发主要是因为效率
2003-10-20 17:44:04 程云()
这是中间层的对象重用的问题了，
2003-10-20 17:44:22 FrameSniper()
什么意思，理解不了，可以大概说说思路吗
2003-10-20 17:44:36 生命如歌()
这是中间层的对象重用的问题了，我刚才就问了没有回答
2003-10-20 17:45:05 FrameSniper()
我有点不太明白你们说的中间层建立缓冲机制和对象重用的问题
2003-10-20 17:45:15 FrameSniper()
我有点不太明白你们说的中间层建立缓冲机制和对象重用的问题
2003-10-20 17:45:21 程云()
还有很多中间层的特性的问题，
很多功能用单层两层都是无法实现的，
而，多层就可以轻松作到，
这不是一两句说明白的，
多数是要自己亲身作一下，才可清楚的
2003-10-20 17:45:38 阿朱()
大型系统面临的最大的问题就是：定制耗用了大量时间。
架构就是为了解决稳定性，安全性，日志跟踪，封装数据提交复杂性，流程定制
架构需要数据库架构，中间层，客户端一起配合，不能是单独运作的
2003-10-20 17:47:01 FrameSniper()
阿朱，给推荐几本你认为比较适合偶这个水平的人看的软件架构的书吧
2003-10-20 17:47:02 程云()
对象重用，
不只是一个功能可供多个客户端同时使用，
也是读取的一组数据，可满足多个客户端同时使用上，
这就算是一个简单的数据缓冲了，
这样，每一个客户端不必都去读一次数据库
而只让中间层读取一次就可
2003-10-20 17:47:29 FrameSniper()
呵呵，类似DLL的调用机制
2003-10-20 17:47:42 FrameSniper()
一次载入，多次使用
2003-10-20 17:47:43 程云()
不不，比那强大的多，
2003-10-20 17:47:57 FrameSniper()
我知道，我就是作个比喻
2003-10-20 17:48:25 FrameSniper()
你的意思对象重用这种机制的实现必须依靠数据缓冲做辅助
2003-10-20 17:49:03 程云()
差不多吧，
还可建立对象回收机制，
这样，一个客户端在完成一个功能后，
释放了一个中间层对象，
但这个对象并不马上消失，
而是还存在一段时间，
如这时有另一个客户使用它，
那可不必再重建立，而可直接使用它就可
这叫对象缓冲和回收
2003-10-20 17:49:07 阿朱()
关于软件架构，一般都没有人写书，因为读者太少，而且能写此类书的人太少，还有就是这些都很宝贵一般不轻易写
所以我也没有看见，只是自己在多年设计开发实施中总结的
2003-10-20 17:49:49 程云()
有本清华出的《软件构架实践》一书
还凑合，可看一下
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
因为讲师工作都特别忙，
估计在这次培训之前，我也只能整理这一份《讲师闲谈录》了
但如果以后还有类似培训，我争取再继续出后期。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>