不是架构的架构之一：总体思路

涉足企业信息化行业已经有了七八年了，这个行业一直都是各种架构泛滥的场所，由于本人也是个喜欢尝试新鲜事物的人，这些年在各种项目中尝试过很多当时流行的架构，自己也瞎鼓捣出了很多个所谓架构的东西。这段时间因为养病，正好有时间有精力，又鼓捣出了一个似是而非的东西，不过总算是自己多年的积累，丑媳妇总要见公婆，东西也总归要派上用场，才拿出来献丑，贻笑方家。下面将我从选择平台到各种第三方代码的选择等几个方面来描述。

 

何谓企业信息化

准确的定义在google可以搜索到一大把，我只说下自己的理解。

1.在这个领域，核心是业务，技术是围绕业务而生。

2.通常情况下，应用是围绕着数据展开（是数据，不一定是数据库），数据项较多，数据之间的关联较多，对数据的完整性要求高，不能接受数据缺失和关联错误。

3.通常情况下，对系统性能的要求不高，略微的延时和等待都是可以接受。

4.并发适中，在较多用户的情况下，需要考虑并发处理的问题。

5.界面复杂，如果要赢得较好的用户体验，使用标准控件远不够。需要自行研发，或购买第三方控件。

6.部署。通常企业会有自己的服务器和管理员，如果是桌面应用，需要使用合适的方式来处理大量客户端的安装和程序更新。

 

事实上，企业信息化是个宽泛的概念，上面所述和我所接触的只是其中的一小块，也叫MIS系统（信息管理系统），除了MIS应用，应该还有数据挖掘、应用集成等领域。

 

适合信息管理系统的开发工具

这里也许会引发很多的争论。

的确，如果需要最高的性能，C++无疑是首选，Delphi似乎也不错；

如果需要最快速的开发，最酷炫的功能，Ruby On Rails，Dojango都是良好的选择；

做Web前端的开发，无疑PHP是首选；

但是，当今大多数信息管理系统都不是选择的以上的平台，反而最多的是建立在最没有特点的J2EE和.Net平台上。

 

“重剑无锋、大巧不工”

正如《神雕侠侣》中的两句名句，java和C#就是这样的语言。我们需要在快速开发和软件工程化之间找到一个平衡，我们可以需要像C++这样的性能，但无法接受他的开发效率，可以需要动态语言的开发效率，但无法接受他的太灵活，像橡皮泥一样难以工程化。

 

好吧，切入正题，实现我的这个似是而非的架构，用的是C#语言，当然也很容易的迁移到java平台上。

 

主要思路：

一、可以部署在局域网或者互联网上，而不需要做额外的开发和损失性能。

通常情况下，部署在局域网中的应用，会直接连接数据库，这样可以获得最好的性能，应用的开发也很容易，但是要迁移到互联网上就没这么容易，这时，通常会将局域网应用中的业务层部署到一台应用服务器上，然后在业务层上再开发一层服务层，通过WCF或者其他方式发布，客户端代码可能也需要做出大量的修改。

反之，如果一开始就决定开发基于WCF的应用，很好，现在可以同时在互联网和局域网中使用，不幸的是，开发起来有一点繁琐，更麻烦的是，对于局域网应用来说，通过WCF服务反复序列化和反序列化，性能上要远低于直接访问数据库。

对于这样的问题，已经有了现成的解决方案，例如CSLA.net。为什么不直接用CSLA，请参照第二点。我的解决方案和CSLA类似，但是更简单，侵入性很弱。这个在以后再详述。

二、开源的、第三方现成解决方案的取舍

前面说过，这个领域是个架构泛滥的领域，有太多的开源的框架可以选择，作为我们而言，需要理智的做出取舍，特别是结合各自项目的领域。

我的看法：

　　1.开源的框架解决的问题领域和项目的领域重叠小，而且这部分问题自己开发花费的代价不大，则选择自行开发。

　　2.开源的解决方案对项目的侵入性太大，谨慎使用。所谓侵入性，就是项目对该框架的依赖性，依赖性越大，如果以后一旦该框架无法满足需要，而从项目中剥离开这些框架的依赖会十分的痛苦。

嗯，前面提到的CSLA.net框架就属于上面的第二点，要用到它的数据门户(DataProtal)，必须要使用它的业务对象，虽然这是个很优秀的框架，但是我们并不需要这么多额外的内容，好像我买了个电视遥控器，非要搭配一个电视机一样。

三、开发效率的考虑

开发效率当时是一个主要考虑的问题，一个好的框架，使用起来一定非常简单，简单的代码就可以让应用跑起来，如同不需要通读汽车说明书，才能开车一样。

在这里，我们需要让框架更强大和灵活，同时也需要适度的自动生成代码。

自动生成的代码，一定不能太复杂，不能太臃肿，甚至我们可以随时离开代码生成器可以手工编写，而且自动生成的代码必须和手工补充的代码同时存在，和平共处。

四、数据访问层的考虑和ORM的取舍

当然，目前有很多现成的ORM方案可以选择，用作数据访问层的框架。

随着.Net4.0一起发布的Entity Framework和Linq2SQL都是优秀的ORM框架,但是有个共同的问题,就是生成的代码太多,太臃肿。我们离开了设计器就无法工作，背后做的太多事情，如果不深入研究，也难以控制。

相比而言，NHibernate似乎是个不错的选择,侵入性很小,将来用其他的框架替换他，代价也还可以接受,性能上似乎也不错。

好吧，NH作为一个备选方案。不过，我们也许不需要真正的Object Mapping，这时一个简单的Entity也许就够了。

五、更多的问题考虑

其实还有更多的考虑，只是一时间难以列出，在以后的随笔中逐步阐述吧。

 

水平有限，考虑不周之处，请多多指正。

下篇预告：不是架构的架构之二：系统基础