实战项目分析续（解答问题）

拙文《实战项目分析》发表之后，很多朋友留言，讨论比较热烈，我也对一些朋友的留言做个回复，一起交流，共同提高！

 

1.     关于避免业务实体贯穿多层的问题

首先强调，分层架构下，我们要尽量避免的是牵一发而动全身，但某些时候这是必然的，任何方案只能解决部分问题，而不是所有问题，而且往往一个新的方案会带来新的问题。

我列出我能想到的几种解决方案，并且使用一个典型的“加字段”的例子各自说明优缺点：

a.       每个层使用自己的模型，传递时翻译。比如使用DataContract，BusinessEntity，DataTable分别对应表现层，业务逻辑层，数据存取层的领域模型，传递时在各层之间翻译。这样可以起到分离的作用。WCF在这方面就做的很好，它强制开发者使用DataContract约定系统的数据接口，而屏蔽其实现。

这种方案是最常用的，但不能很好地解决加字段的问题，当需要加一个字段时，DT、BE、DC都需要修改。而且翻译动作会带来一些效率上的损失。

b.       各层使用同一个模型，例如都使用业务对象。利用C#的partial类，各层只定义自己关心的数据，也可以起到隔离的效果。我见过一个老外的项目这么设计。

这个方案可以部分解决“加字段”的问题。首先我们在数据库表中增加一个字段，在数据存取层的partial类中加一个Property，然后加一行赋值语句，最后在展现层加一个控件。这样就避免了修改业务逻辑层（当然是业务逻辑层不处理该字段的情况下）。这个方案虽然能解决加字段的问题，但会由于带来partial类太分散造成代码阅读困难。

c.       让数据自描述。即数据本身包含元数据，如使用XML。但这也会带来另一个问题，这样的会走向另一个极端，就是弱化了面向对象。任何的数据都是XML，就没有了面向对象的优势。当然你也可以再搭建一个XML到对象的转化平台，但会增加很多工作量。

如果平台搭建的好的话，可以解决“加字段”的问题，因为XML是自描述的，可以加很多元数据进去，描述数据在各层的属性（例如数据结构，是否被转换为对象，是否在界面上可见等）

以上是我目前想到的和见过的几个办法，肯定有问题，这里抛砖引玉，也希望大家多多指正。

 

2.     面向接口编程的问题

大家对这个也比较关注。我在这里澄清一下：我没有说接口是万能的，接口肯定不是万能的，也不可能解决所有的问题。我说的只是接口是消除依赖的基础，是现阶段面向对象领域实现消除依赖的主要手段。

在现在这个面向对象为主要理论基础的时期，包括设计模式也好，架构模式也好，其中一个核心的思想就是消除依赖，封装变化，而接口正是其主要手段。

欢迎大家继续讨论！：-）