貌似一定要用mater才行.

工厂，单例

是的,面向过程和面向对象并不冲突,在项目中经常可以交替使用.

云里雾里的

蛮00的嘛。。。工厂模式？

项目描述： 在Openfire+Spark的即时通讯(IM)系统基础上修改，了解WBN版的开发.根据我方的需求进行一些修改、删减，主要是相关功能的删减。之后部署该系统，并进行测试。竞标者需熟悉此系统，有过相关经验者为佳！
了解 ajax应用! 报酬面议!
QQ:147858017

你好,我按你的步骤去做,但是却显示:Application class {WebAppProMeshDemo.Application,WebAppProMeshDemo} could not be loaded.我已经建立一个类项目WebAppProMeshDemo，里面就包含Application和PageControllers文件夹，分别包含Application.cs和index.cs
接着建立了ProMeshWeb网站项目，引用了WebAppProMeshDemo.dll和Activa.ProMesh.dll库文件，运行的时候却出现上述问题。请问这个是什么问题？要升级到VS2005 SP1才行的吗？谢谢！

这个东西可不简单呀!你看他的模板引擎没有?

也不算很有趣，只是struct是valuetype的，所以当运行llist[i].Update(i+1);的时候，实际上运行的是
MyStruct item = llist[i];
item.Update(i+1);
这里item是llist[i]的一个复制品，原件llist[i]并没有执行update，所以当然还是0。
这跟byval和byref有点类似，都是valuetype才有的“麻烦”，一般的object就都是byref了。

1，概念不一致: 实际上是不同的概念， 只是同一个名词。用户的概念 和 系统的概念是有转换的。
2，多界面：都另外收钱

3，4看具体情况

@怪怪
恩，我明白，这样所得到的半形式化语言，它应该就是通用语言。客户、领域专家、开发人员都能理解
"使用解释器模式配合配置文件来表达小语言，应对变化。" 这个可能我理解你的意思不深。我想可能会是DSM吧。
有时间要跟你聊聊，学习下。

怎么写项目开发的总结。*

@bmrxntfj
不是DDD， DDD大半需要围绕领域对象展开， LZ的问题并得不到真正的解决。形式化、半形式化的语言， 以什么展开考虑因素要多得多， 所以解决问题的手段也更加根本。

关于概念不一致的问题，开发初期建立用户术语表和开发术语表是非常重要的步骤，而且必须要经过客户方的认可，否则将难以为继。
说到主动被动，其实大多数情况是客户不成熟，我们也不成熟。

--引用--------------------------------------------------
Aldebaran's Home: 感觉你做项目太被动，其实一开始你是最主动的一方，你应该将一些基础的东西（例如工号）灌输给用户，而不能询问他们你们想怎样，用户不都是对的。
--------------------------------------------------------

这点启发很大，有时候是太被动了

@水果阿生
建议非常好，最好是拉几个不怕死的。

@老怪物
你这是DDD哦。呵呵

的确,如果客户占主动权那么后果绝对非常悲惨

特殊处理，千万别特殊处理，一有了特殊处理，遇到什么事情都 ‘特殊处理’ 一下吧，我现在的苦恼！

看看客户所说的话， 能不能整理为一个自然语言的子集：与业务相关的小语言，并形式化。 实现过程可以三步走：

1. 对需要变化的业务规则建立统一的模型。

2. 使用解释器模式配合配置文件来表达小语言，应对变化。

3. 当2变得复杂和难于掌握， 考虑实现一门业务小语言， 难度较深。

纸上谈兵， 没机会实战过， 而且我估计这个成本对于承接项目的公司恐怕难于接受； 除非在市场上有多家公司需要这种东西， 这样算是预支成本吧。

对于一般技术人员， 可能认为难度在于实现小语言。 其实最难的一部分是如何将业务规则及其变化归纳为一个可接受的表达方式。

感觉你做项目太被动，其实一开始你是最主动的一方，你应该将一些基础的东西（例如工号）灌输给用户，而不能询问他们你们想怎样，用户不都是对的。
操作界面方面最好保持相对的一致，例如每个界面都由增删改按钮和一个列表控件组成，最多在加棵树，如果界面不一致，你将来对用户的培训和维护都将是一个灾难。
与原有其他系统的交互这个问题是挺头痛的，如果没有设计文档的话就需要监视sql语句了，我除了送上没好的祈祷不能帮你什么忙。
业务变更是常见得不能再常见的事情，特殊处理的地方建议写成接口或存储过程比较好。