完了，被锁住了，明天开始卷铺盖到该公司自己的饭店里面入住，要住一个月，一直跟到这个项目结束为止，周六周日也要在那儿加班，好命苦呀。据说那个单位是军工企业，被美军卫星从天上照着，凡在此进入频繁者，不允许入境美国，呜呜呜，明年的MVP Summit参加不了了。
这两天开始进入详细设计阶段，前段时间，项目组的几位负责人最终与需求方定下了需求，当然，我们在详细设计阶段，还是发现了很多需求不清晰的地方，不过，这种情况经常发生，不是吗？
今天上午搭建了代码编写环境，并且初步分派了任务。共分为三组，一组去进行数据库设计，一组进行业务逻辑层的搭建（含数据层），另外一组进行Web设计。
Web组的成员主要是将前期的实用设计界面（即使用HTML+JavaScript搭建的快速原型）翻译为ASP.NET界面，不过不需要写任何代码，只要把相应的模块转换为ASCX就可以，并且签入到VSS当中。
数据库组的人员按照需求方提供的数据字典建立数据库（数据库系统是Oracle 9i，不知道性能如何），并且建立表间关系、存储过程之类的。
而业务逻辑层组的人员主要搭建实体类及业务操作类，以及数据层，同时为了保证结构优化，数据库组与业务逻辑层组的人员每天要会面一次，讲解一下各自的见解。
为了便于日后的NLB或者CLB的扩展需要，Web层将不会直接调用业务逻辑层的东西，而是通过中间的Web Service进行调用（今天演示了一把Web Service的创建，他们感觉非常酷。因为有人原来是使用Java的，现在对.NET服了，用JBuilder写Web Service，光WSDL文件就让人厌烦）。
现在有几个问题，一直没有想好：
- 业务逻辑层中的实体类用什么比较好？是创建自定义的实体类还是直接使用DataSet，使用DataSet便于绑定，而使用自定义的实体类则效率较高。那么使用强类型的DataSet呢？会有什么问题吗？需要今天研究决定。
- 开发过程中如何齐头并进？因为三层结构是纵向分割的，所以会存在相互依赖的关系。难道先是所有人一起上来去做数据层，然后再搭建业务逻辑层，最后一齐完成Web层吗？我不希望这样，所以分为了多组，在两天内不会出现问题，但下周开始，则会有一组人没有事情做。这是我不愿意看到的。
- 缓存是在页面级做好，还是在业务逻辑层实现好？如何把关键层次的运行效率调整好？前几天看了ASP.NET的那个PPT，然后又去访问了http://www.asp.net，发现并没有像他们鼓吹的有多大的改善，甚至跟CSDN一样，越调整，速度越慢了（CSDN这几天成笑话了）。
- 如何掌控程序中的Bug？在目前的态势下，根本没有办法按照MS的那一套来做。虽然我提出过可以使用BMS XP来试试，但项目负责人担心如此一来会使项目组的编程方式发生更改（不过也是，光使用VSS我就感觉他们就不习惯了）。
希望有经验的人能够给我一些见解，我也会在后续的过程中把太极十八式打好，供大家参考。
我在那附近呆了八年，很不错的地方
饭店下面的潮洲菜不仅很贵味道也很好
向南过了路口路东有一家新疆饭馆，烤羊煺和羊肉串很有风味，
路西也有一新疆饭馆，大盘鸡很好
再往南有一家涮肉也不错，
再往南请你女朋友看电影也很好
那地方太好了，我很喜欢那地方
Ｂｕｇ的管理是必须要的，可以使用.net写一个简单的留言回复系统先应付。这样管理可以散漫一点，但没有是不行的。
For save time, can use SharePointService 2k3 to track bug and documents…
强类型的DataSet挺好用的
我现在做的东西，整个Framework都是基于这个，现在代码量已经很大了，还是觉得不错的。有点缺陷，但是容易克服。
不要太担心有人没有事情做，你的任务是完成项目，而不是让所有的人在项目中作事情。
Sharepoint Team Service做一个bug管理可以应付一下。还是很管用的，主要是方便使用，易于上手，看来你们项目里面的人比较适合。
倒， 北京估计又少了很多腐败机会了。
你们需求结束直接就进入 详细设计 了？
军工企业一般都必须遵照GJB438 的，没有概要设计怕是不行的吧
Ginn 说了我要说的。(y)
1. >>>为了便于日后的NLB或者CLB的扩展需要，Web层将不会直接调用业务逻辑层的东西，而是通过中间的Web Service进行调用
understand you want flexibility, but still cannot imagine your presentation will call webservices directly, you’d better encapsulate the calling into another layer
2. >>>业务逻辑层中的实体类用什么比较好？是创建自定义的实体类还是直接使用DataSet，使用DataSet便于绑定，而使用自定义的实体类则效率较高。那么使用强类型的DataSet呢？会有什么问题吗？
the problem with entity classes and strong-typed DataSets is that they are rigid, it seems contradictory with the first decision here. Unless your solution is already fixed in the stone, they might not be a good solution. Of course, it really depends on what kind of stuffs you are dealing with
3. >>>开发过程中如何齐头并进？
if your analysis and design are done well, you should have a clean interfaces betwen the layers now, then theorectically they could work in parallel. But I were you, I would gather the developers around and explain the design decisions clearly, considering they are not experienced from your previous posts
4. >>>如何掌控程序中的Bug？
it is needed, but it is very easy to create a bug tracker. By the way, you don’t have quality assurance/testing people? how big is the project?
我不太懂Web开发，希望你以后多多指导大家
对于第二点“开发过程中如何齐头并进？”
我觉得大家应该先对业务逻辑好好学习，除了数据层，另外的两个组先做自己的部分的原型，到了底层定了下来进行改动，拙见。
正如saucer所说，我现在通常的做法是用Facade包装WebService，Client通过Facade调用WebService
Facade负责Cookie认证等杂务，并负责DataSet到强类型的转换，因为你自定义的类型直接用在WebService并不是很好的事情。
我在这个项目组的位置十分尴尬的说，所以很多事情虽然想到了，也无能为力，只能借助我对.NET的了解进行简单的介绍。
甚至于三层他们现在也不能接受的说。
1. 同意saucer的说法，虽说是三层“分布式”应用程序，应用内部层间调用也尽量不要跨网络，任何远程方法调用速度都是很慢的（还不是一点儿半点儿，Web Service最慢但是基于标准，Remoting w/HTTP+SOAP其次好不了哪儿去，Remoting w/TCP+Binary好些但也绝对不适用一般意义上的层间调用）。在基本执行效率都无法保障的时候，可伸缩性再好也没有什么意义了。至于说为了NLB/CLB，首先界面层最好是无状态的以便于日后采用NLB（哪怕使用ASP.NET State Server做状态存储，在每个Web Server上的CPU仍会有额外开销，影响性能和可伸缩性）；业务层的组件也应该设计成无状态的。除非必要，一般使用三层代码集中部署、从前端进行无状态负载均衡就足够了，使用CLB会引入额外的问题。
按照.NET应用程序设计的概念，你应该将业务层的组件通过service interfaces组件（也就是以前常说的business facades）封装供外部应用系统（而不是内部系统中的任何部分）使用。在这一点上看，这类组件可以认为是界面交互层的一种特例（只不过不是给人看，而是给机器“看”罢了）。
2. 业务实体类可以有多种设计考虑，既然开心比较注重效率，那么就使用自定义实体类没问题的，包括数据绑定其实和DataSet是一样的（实体类肯定定义了public的属性吧），且对象的创建和管理开销也会小一些（Pet Shop 3.0+/ASP.NET Forums等等都是这么用的，Duwamish使用DataSet导致性能严重低下）。从执行开销和效率的角度讲，强类型DataSet和DataSet相比没有什么本质不同，在数据量不大的调用中绝对不是最佳选择（顶多做做内部缓冲的说）。
3. 如思归所说，三层应用程序在逻辑设计完成时/物理设计开始时，层间调用已经有了明确的接口或协议，因此完全可以相对独立的并行开发。我的经验是在业务层实体关系与组件交互已经确定的前提下，优先确定两端的实现（即界面和数据库）。确定界面有助于相关文档的工作同步展开，同时也确定了对业务层的使用需求；确定数据库结构是因为其对数据访问层乃至业务层中的某些环节的设计会有较明显的影响。在开发业务层的时候可以通过已经确定的数据服务层接口，先使用基于伪数据或使用内存的数据服务组件以保障业务层的开发和正常调试。当数据库或外部数据访问机制确定后再将其按照之前的数据访问接口封装。还是那句话，层间互动的协议应该首先相对明确，然后开发才好安排和协调。
4. 关于缓存，在不同的层会有不同的需求和策略，不好一概而论。一般来讲界面层的界面组件应该缓冲生成的客户端代码结果，界面处理组件缓冲一些用户信息、相对稳定的业务数据、配置数据等等，业务实体类有很多可以缓冲的信息，实现上比较机动灵活，数据访问组件也可以缓冲一些关于数据架构的信息（但绝不能缓冲同数据库的连接就是了）。具体的可以参看MSDN中的相关文档吧。
如果项目组对于三层结构的.NET开发还不能认同，可以结合一些例程（如.NET Pet Shop 3.2）给他们先培训一下，还有最关键的那本Application Architecture for .NET: Designing Applications and Services，我想很快这些顾虑就可以打消了吧。
以上拙见大家见笑。：）
我比较习惯于模块开发，独立完成各个层
给Soap搞个Compression
也就是做一个SoapExtension，在传输前后做zip压缩。
如果网路很慢，是非常有效的方案。
尤其是每次传递都是几十K的数据量，而网速只有每秒十几K
另外，减少web调用次数，也有提高。
To JGTM’2003 :十分感谢您的建议，不过我估计在我目前这个项目中，我可能搭建不起来这个实际的应用，因为正如我在《一起来打太极（1）》中所描述的一样：我现在所在的团队并不是一个成熟的团队，而是一个从各种语言转型到.NET当中来的，甚至很多人没有做过B/S开发。
而项目只有一个月，前面在我没有来之前，他们光需求确认就已经花销了将近一周的时间。
这几天我又在培训ASP.NET以及VSS等工具的应用，所以又浪费了很多时间。
总的来说，我感觉有一些盲目头绪，不知道哪位有过类似的经验，讲一下如何做？
对了，项目需求书不是65页，而是161页。:(
我有类似的经历,首要的一次事是,放松,不要着急,车到山前必有路,
再就是要追求完成任务, 不要追求技术也不要追求完美,
事情不重要,关系更重要,对事情要负责,但不要对别人要求太严格,跟大家搞好关系.
To blueinkstone:我现在的确还没有开始严格起来。不过他们的项目负责人够严格。因为总的来说，我只是一个技术顾问的身份。
既然如此，倒不如在这个版本RAD一下先把业务都走下来，这方面即使是新手，恶补一下.NET，再配合VS.NET，应该还是搞得定的。就别放太多时间指望团队能够完全理解三层开发中涉及的各类组件分工和开发准则了。把一切时间放在逐项实现（哪怕不是很完美的实现）需求中涉及的功能上，这可能是您完成项目唯一的出路喽！:(
总之，采用三层结构设计的应用项目开发光靠这样的资源（时间和人）实在是不太现实，因为采用多层软件架构确实会引入更多的工作量（好处自不必多说）。所以如果能够说服项目的负责人多分配资源以保障软件项目（尤其是第一个版本）的架构设计则是最理想的了。
比较同情开心，这简直是让你用焖米饭的时间熬米粥啊，况且给的材料还不是大米是棒子面儿，所以你只能RAD一锅方便粥啦——咦，一提起棒子面儿粥，我这口水……嘿。
强类型DataSet 在对象的创建时花费内存多，你还可以在编译后找到强类型DataSet 自动生成的 .cs文件
到这学习一下哦 ^_^
不过，１个月？而且人员好像都是生手。没道理。
对于开心是没有问题的，假如都是老手，就不需要开心了
我也觉得开心在这样的情况下，最好能够实行步步为营的战术，不要一开始就想让所有成员都理解你的设计，把项目成功完成才是最重要的，只要体现了需求，我想设计上不是太完美也是可以忽略的遗憾，不过，我想整个过程开心个人的投入可能会比较大，毕竟成员间的协作程度可能不高，而你的作用和工作量必然增加。
呵呵，胡乱说的些感想，如果有什么唐突了，希望开心多多谅解。
不知道开心和各位朋友乐意不乐意交我这个朋友–yufan(lob)？
MSN：[email protected]
本人正在学习.Net,可惜中间有很多疑惑和迷茫，所以也希望能向各位朋友多多学习。
一个月时间太短了，这不是赶鸭子上架吗？你公司也太不人道了。