没头没尾--项目开发笔记：C#分布式工程的修改版本
没头没尾--项目开发笔记：C#分布式工程的修改版本
没头没尾--项目开发笔记：C#分布式工程的修改版本 标题：没头没尾--项目开发笔记：C#分布式工程的修改版本
关键词：分布式开发 C# 项目分工 DELPHI与C#的混合开发
11月20号：有点兴奋有点困
说回忆实在有点麻烦，我还是直接跳到目前的项目状态来讲讲我们是怎么具体实现的吧。
接着昨天下午的写吧。我想首先对我们具体实现的工程过程用最简单的方式描述一下。
一开始我们给客户做一个ASP.NET的实现，然后根据我们的调研发现ASP.NET的实现方式并不合适给用户，用户可能一天要录入进千张单据。如果在网页上录可能用纯的键盘操作方式不太好实现，还有就是报表（其实这都是废话，我以前写的程序直接从网页上打印也没问题，直接写一个纯键盘方式的单据也没有问题，不过开发的效率没有写一个应用程序的客户端高而已，换言之，也就是蒙客户。）所以我们就用Webserviee作为中间的数据传递层，用C#开发服务器与Servcr。给客户演示之后客户还比较满意。可是客户要安装一个DEMO的时候出现问题了，客户要求他的下级可以直接从网上来安装这个，而且不能对客户端有操作系统的强行要求（靠，中国搞销售的小公司机器真是烂呀，想象一下在PII的机器上装一个NET Framework.. L）。那么用VS.net开发客户端的方案又被搞死。还好Team里有几个Delphi的牛人，两天之内搞出一个Delphi开发的连接VS.net开发的Web Service的客户端。最后客户拍板，就用这个了，下面就来说说这个实现的架构吧。（喝口水先）
我们的工程Server端有下面9个工程：（哈，一下子就比Microsoft开发的架子多了几个。）
1. CommonData
首先生成的是这个目录；这个目录中存放的是通过VS.net开发环境生成的XSD文件以及xsd.exe生成的对应的文件。是对数据库的描述。最后生成的是从类视图中可以看出对应的类，是一堆继承DataSet的类。
2. DataAccess.Base
使用VS.net生成的数据库的访问的文件，是一堆组件类（说实话，我也不知道组件类与一般的类有什么区别。）比如对应一张表Product，就会对应的insert，update，delete的sqlcommond生成。
3. DataAccess.Template
这个工程是兄弟部门写一个小的PERL程序，生成一堆文件。把DataAccess.Base类做了一次继承，加入了一些对于数据库最基本的操作，比如新增数据，删除数据，修改数据。通过KEYID来查询一条数据等等。也就是把数据的操作都变成函数，不会在去调用什么sqlcommond之类的System.Data的对象。每次DataAccess.Base更新后，此类文件也同步更新。
4. DataAccess
最后这个工程的产生是因为上面的工程是PERL生成的，那么如果我们还有很多针对的业务方法在开发的过程中写在里面的话，那么可能数据库有变化，我们没有办法再次使用PERL的工具来重新生成DataAccess.Template文件(会将开发过程手工写的代码覆盖)。所以我们又继承了一次DataAccess.Template。所有特殊的方法都是写在这个地方。
5. CommonFunction
这个没什么好说，公用的方法，公用的函数都是放在这里，比如单据号的生成工具，WebService的加密算法类。。。所有要写一个工程的都几乎要有这种Common的东东吧。
6. StaticData
这个文件目录中的文件主要的目的是为了数据在服务器上进行缓存处理。我把CommonData目录下所有的文件都重新的做出一个STATICDATA文件，我称为SO，这个SO将会记录数据最后被更新的时间，是否需要进行缓存的标记等等。然后作为一个对象存储在服务器的Application的对象中。
7. BusinessFacade
这部分说白了就是什么都不干，就是提供给不同的业务client。写了一大堆的方法就是把client传过来的数据直接传给business rules。主要的用途我想有下面两个
a)从数据库的表设计到界面层的业务实际上是两种思路，这两种思路从根本上是不相同的，就好比较界面我们是面向结构，数据库是面向对象的。现在这两东东接口好定，可是在什么地方做这两个的接口，有什么规则？我个人认为FACADE可以来搞这件事，也就是。FACADE可以按结构来组织，来调用按对象组织的rules。
b) 可能会有很多种client，比如web service，以及WinForm，或WebForm。如果你的系统中会有几种client共存，还是有一个这个业务外观层比较好，层次调用清楚一点。
8. BusinessRules
这个部分从分层的设计上来比较简单。我们把所有用户对界面的操作对业务的修改与查询都放在这个层。这个层关心纯粹是业务。
9. SystemFrameworks
系统运行过程中用到的系统对象。本系统中主要生成一些对应Web Service应用中要用的Application控制，Session控制。
客户端DELPHI我不熟悉，只要要求了采用封装的方法来解决权限实现，日志的统一处理，还是直接把C#的XSD文件直接生Delphi的clientDataSet的结构。
调用的方法一般流程是这样子的：
界面取数据的消息 ——》WebService ——》Facade ——》Rules ——》DataAccess(调用继承的方法会调到DataAccess.Template与DataAccess.Base) ——》数据库。
还有一些特殊的，比如调用缓存数据的过程描述起来有点麻烦。这就不详述了。
生成这个框架要注意以下一些问题：
l 框架中的工程一生成就要上Sourcesafe(废话)
l 框架中的工程一生成就要去定义出命名空间（特别是CommonData，使用VS.net生成XSD文件时带的CS文件将不会解决方案中找到，回头要修改命名空间会很麻烦。）
l 一定要统一大家的思路。按一种方式来做。应该你可以在每一层都直接去调用数据库的方法来对数据库进行操作。如果你不强制的定清楚，最后开发出来的工程就会是一个很搞笑的工程。（在WEBSERVICE时直接调用DataAccess来写数据库？）
l 还有一点是我在把WebService上Sourcesafe的时候总是处理不好，可能是与我的IIS的设置有关系。不过调整了几次也没调好。郁闷，后来也不知道怎么回事就好了。
不知道大家看完这个有什么感觉，反正我写完之后就开始回想，我们花了多少时间把一件简单的事情搞的这么复杂，还要定出规则让开发的人员来学习，这件事情是不是会有必要？其实我想，和昨天下午说的一样，我们的出发点是将开发的过程量化，分开。用层次清楚（效率不是最好）的框架来实现高效的开发。但这个过程的推广是痛苦的，有时我自己也会怀疑这样做对不对。会不会真的可以改变以后这家公司的开发流程从而改变开发队伍的人员结构。真的带来好处？我想这个问题谁也回答不了。不过我认为有一点我是肯定的，开发的方式一定会变化，会变成可以通过分工来降低开发人员的整体水平。以及新的开发方式将会减少个性化编程带来的很多无谓的BUG。
下面几个开发笔记主要是讲讲开发的过程中一些思考以及做出的一些小工具。首先讲讲对FACADE中面向对象与面向结构交互时的一些相法。
