我不清除目前有什么比较好的理论指导，让项目的结构稍微有点层次感。
目前项目代码很简单，但耦合太大，可以说是以界面为准的。比如，查看所有的合同。我们的操作是直接使用ado.net与数据库通讯，返回所有的合同后，将其数据集绑定到DataGrid。紧接着提供链接，可以让用户查看某个合同的具体细节。
这样做，很本能，很直接，也很有效。但是，前提要求客户需求稳定。至于，它的弊端，我想有过实际经验的人都知道。我在这里也不多说了。
今天的重点不是数落这种初级的思维方式。我的疑难是如何有效地转变这种方式。换句话说，是该用哪种方式去代替她。
考虑了很多，我还是觉得套用ORM这些看似比较庞大的架构很不实际 （我考虑过ORM。但感觉ORM会不适合需求不稳定的项目。对ORM我不是很了解，更谈不上实战经验）。
另外，对于不大的项目来说，工期短，客户需求模糊。所有的因素决定了我们要在变化当中找出不变的东西来，并把他抽象出来。
当一些看似在变的实体被抽象出来后，我们也就能把中心从界面转移到更加重要的业务逻辑上来。我感觉这样做了之后，至少层次会更清晰。耦合度也将降低，之后的维护工作也会变得更简单。
泛泛之谈，一般没有什么意义。因此，打算对已做过的项目重新分析一下，统计出些比较实用的原则。
目前项目代码很简单，但耦合太大，可以说是以界面为准的。比如，查看所有的合同。我们的操作是直接使用ado.net与数据库通讯，返回所有的合同后，将其数据集绑定到DataGrid。紧接着提供链接，可以让用户查看某个合同的具体细节。
这样做，很本能，很直接，也很有效。但是，前提要求客户需求稳定。至于，它的弊端，我想有过实际经验的人都知道。我在这里也不多说了。
今天的重点不是数落这种初级的思维方式。我的疑难是如何有效地转变这种方式。换句话说，是该用哪种方式去代替她。
考虑了很多，我还是觉得套用ORM这些看似比较庞大的架构很不实际 （我考虑过ORM。但感觉ORM会不适合需求不稳定的项目。对ORM我不是很了解，更谈不上实战经验）。
另外，对于不大的项目来说，工期短，客户需求模糊。所有的因素决定了我们要在变化当中找出不变的东西来，并把他抽象出来。
当一些看似在变的实体被抽象出来后，我们也就能把中心从界面转移到更加重要的业务逻辑上来。我感觉这样做了之后，至少层次会更清晰。耦合度也将降低，之后的维护工作也会变得更简单。
泛泛之谈，一般没有什么意义。因此，打算对已做过的项目重新分析一下，统计出些比较实用的原则。
