从ASP向ASP.NET跃进的第一步！

发信人: sakawinki (papaya), 信区: DotNET
标  题: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Tue Sep 27 08:39:39 2005), 站内

请教了！

实际问题：要实现各产品生产流程的各工序的各种数据全记录；
1、工序一：操作时间，操作人，数据1，数据2，操作情况，操作结果；
2、工序二：操作时间，操作人，数据1，数据2，数据3，操作情况，操作结果；
......
每个工序记录的内容除了 数据项 不同外，其余的都相似，
而我们有很多产品，每个产品有相同的工序，也有完全不同的工序。

我现在做的：由于原来比较傻，我是把每个工序做了一个页面，
在每个页面中对不同产品进行筛选调整，现在感觉做得很差。
因为产品会越来越多，但产品工序相差就那么几项，每个工序之间相差的也就数据项，每出一个产品，我都要去每个工序的页面中加switch case显示并记录不同的内容。我怎样设计一个类，或者组件类，使得程序可扩展性强一些呢？

请大家帮忙想想办法，谢谢了！


发信人: Nineteen (^oo^), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Tue Sep 27 09:10:52 2005), 站内

看一看Factory模式、Command模式和Pipeline模式（java那边更多是叫做Responsibility Chain) 名字是死的，模式也是死的，但思想是活的，借鉴一下，你的问题很容易解决。


发信人: Nineteen (^oo^), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Tue Sep 27 09:14:04 2005), 站内

你还得把业务逻辑和UI拆分开，不然维护起来累死了。结构太乱


发信人: AtomAndBit (原子与比特), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Tue Sep 27 10:01:37 2005), 站内

每个工序记录的内容除了 数据项 不同外，其余的都相似
                       ^^^^^^                 ^^^^
问题是这个相似度多大.还有数据项的结构是否一致?

可选项无非是(1)每个工序自己build自己的UI,这是最不好的方法,但若相似度很低,

数据项差别又很大,只能这样了.再改进就是每个工序有一个builder,build它.这种

方法比switch case要好,各个工序之间没有耦合.

(2)只有一个builder来build全部工序的UI.相似度很高,数据项结构差别不大的情况

下这种方法比较好--关键是能否提炼出比较完备的接口出来.

(3)每个工序有一个Layout()方法,把要显示的数据Layout成一个中间形式,如xml格

式,然后用一个builder,根据xml来build UI.当相似度适中,数据项差别又不是很大

时可用这种方法.但这样对性能会有些影响.

(4)如果除了数据项不同外,没有不同了,并且数据项结构都一样的话,所有工序就可以合并成一个类了.

(5)如果性能不是很关键的话,工序差别又大,又不想把UI和业务层混在一起,可以把每个工序的显示用配置文件来控制.


发信人: sakawinki (papaya), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Tue Sep 27 10:03:02 2005), 站内

对阿，我现在就是没有分开

可我现在什么都不懂，要去看看上面的内容？

我都不知道组件类和类有什么分别，应该设计哪个


发信人: Nineteen (^oo^), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Tue Sep 27 13:14:06 2005), 站内

偶一向不熟UI，偶说说业务层，UI请教一下AtomAndBit，这家伙牛。

首先把所有的工序用抽象出个接口来（或者基类），实现所有的具体工序类。
例如：
public interface IJob
{
    IJob NextJob { get; }
    IContext Process(IContext ctx);
    //IContext,调用上下文,这个东西很灵活了，根据需求自己定义
}

public class jobA : IJob
{
   //...
}

public class jobB : IJob
{
   //...
}

and so on...

创建ProductChainFactory类，用来实现工序的串连，这是生成产品链的基础。

public class ProductChainFactory
{
   public static IJob getProductChain(ConfigurationContext ctx，string productNa
me)
   {
     //推荐使用配置文件来生成产品线，
     //这样即插即用，连编译都免了，而且不同工序的实现可以在不同的程序集中
     //例如，一个产品线元素：
     //<product>
     //     <name>product1</name>
     //     <jobs>
     //          <job name="jobA" assembly="yourAssemblyA"/>
     //          <job name="jobB" assembly="yourAssemblyB"/>
     //     </jobs>
     //</product>
 }
   //...
}

客户端调用方式很明显，不多说了。大致架构就是这样。

这还会会涉及到很多技术，例如反射，Singleton等等。为了第一时间观察到配置文件的改变，可能需要FileSystemWatcher，观察到改变之后需要UnloadDomain，然后重新加载Domain，都是细节，就不多说了。


发信人: sakawinki (papaya), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Wed Sep 28 00:40:09 2005), 站内

非常感谢两位的帮助和指导，虽然我还是一知半解，不过我可以在说明一下：

工序都是链式的，即从“下生产订单”开始，

依次到“接受订单”-〉“生成产品序列号”，然后

由生产订单的选择，显示出相应产品序列号。

到达工序 N 的时候，如果产品工序 N 的操作结果是 1，即通过，则在工序 N+1 中才显示该产品序列号，可以对它进行 工序 N+1 的操作，否则工序 N 中将一直显示该序列号表示未通过操作，该产品序列号也不会在后续工序中显示。

具体每个工序必须记录的内容是：
操作员、操作时间、操作情况（nvarchar）、操作结果（bit）
不同的地方是记录某些工序独有的数据：
可能有的工序记录一个电压值，有的记录一个出错率，有的记录一个峰值等等。

在UI上，我现在是上面一个DataGrid实现提交记录，下面一个DataGrid显示记录的内容，界面每个工序都差不多，就是填报数据项的标示不一样，输入主要就是文本框，也有用复选框的，当然，重要的一点是，不同的产品是不同的表，所以后台还要判断是那种产品再对哪个表操作。

最郁闷的是，每多一个产品，我就设计了N个视图，不过存储过程还是帮上了一些忙，在显示数据时用的Datagrid就是用存储过程分页，感觉还能应付越来越多的产品。


发信人: Nineteen (^oo^), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Wed Sep 28 09:09:57 2005), 站内

你的问题,主要集中在扩展性上.

整体架构上,PipeLine模式对你的问题貌似非常对证,^_^

你可以从网上搜索一下"职责链模式"或者"Responsibility Chain".可能都是java的代码.

把所有的工序都拆分成小的零件,根据配置生成产品线.

这样,所有的工序都可以复用,产品线也可以根据需求随时改变,扩展性很好.

PipeLine上,连接节点的消息可以理解成调用上下文.

这个不能再多说了,说不下去了,理解PipeLine可以看看WSE里面的PipeLine类源代码

google一下基于消息的函数调用也很有帮助.
<.net本质论>里面高级方法一章介绍.net中内侄的对aop支持的那一部分大概介绍了基于消息的调用的基本思想.

无聊的时候看看soap协议,那东西整个就是基于消息的,然后你就会感觉你的问题其实不是那么麻烦.


发信人: sakawinki (papaya), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Wed Sep 28 10:07:59 2005), 站内

好的！

瓦！看到你们的回帖真的好感动！让我对自己做的这个东西更有兴趣了。

原先我一直用asp的老套路做，感觉又累又没技术含量，看来这是行不通了，
我终于要学习高深点的东西了。


发信人: AtomAndBit (原子与比特), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Wed Sep 28 12:13:57 2005), 站内

整体设计参照斑竹文章.偶对ASP.NET不熟,啊啊啊啊啊啊啊......我只说说大致应该怎么做吧,具体实现就不说了.对于单个工序的UI部分吧,最好是用xml配置文件来配置显示逻辑.

以工序中提交记录部分为例吧:

1,每个工序有Items,可以get,set,储存key-value对.里面是你要显示的数据项.

2,每个产品写一个配置文件,里面有产品对应的表名,工序......

3,每个工序节点应该包含:key,控件名称,控件ID,控件属性信息

4,写一个静态类ControlFactory,能够根据工序节点的key,控件名称,控件ID,控件属性,生成相应的控件.

4,每个页面有一个UIControlsBuilder,读取配置文件,调用ControlFactory依次产生相应的控件.

5,每个页面有一个Adapter,当点提交按钮时,触发Adapter,把指定控件ID的值提交到每个工序的Items.接口要设计好.

说明:

从配置文件中生成控件可以用反射,可以用switch case,前者灵活性高,后者性能好.也可以在ControlsFactory中用Hashtable储存一系列Control的模板,根据key直接复制.

思路是这样的思路,要根据实际情况进行取舍.比如你用DataGrid实现提交记录,上面很多可能就免了,比如配置文件甚至都可以不要,直接根据Items的key都可以,要赶活的话可以这样做.

最好找成熟或半成熟的框架,实在不行自己写代码量应该不是很大.每增加产品也就是写一个配置文件了,整体看起来非常清晰.

数据库部分也可以用这种方法干,不要多用存储过程,视图什么的.你这一个产品非常复杂,这样的话,要维护数据库端的代码,要维护UI端的代码,很不好呀.最好用一个配置文件来管理产品(工序)的UI,实体,数据接入的复杂性.

btw.说两句闲话.AOP首先应该是一种思想,然后是方法,框架什么的.以这里的产品为例,产品的复杂性有3个维度:实体维,UI维和数据接入维,散落在代码的各处.实体维在C#文件里面,UI维在aspx文件里面,数据接入维在数据库端存储过程,视图上,这样维护起来非常的麻烦.所谓AOP,就是要想能不能把这些东西,这些点织出来放在一个地方控制,最好是不需要重编译.


发信人: Nineteen (^oo^), 信区: DotNET
标  题: Re: 关于我这个实际问题怎样设计类或组件
发信站: 水木社区 (Wed Sep 28 13:09:45 2005), 站内

re"先思想后方法和框架",^_^