关于软件架构的一点想法（1）

关于软件架构的一点想法

总想给自己总结一下，好好想想一个软件的架构怎么写才是尽量好的。

我见过很多大型的系统，ERP，CRM，OA等等，C/S的，B/S的都见过，国内国外的管理类软件系统基本上都看了看（吹牛吧），各式各样的也都算见过吧。但是关于软件的扩展问题都是一个非常痛苦的事情，而我自己也时常开发一些东东出来给自己用。在这个开发过程当中，自己也时常为软件的架构，升级，语言包，配置，脱机使用，模块化开发等等问题而伤脑子。所以老是在想自己写一个软件架构出来，无论其B/S结构还是C/S结构都是没有问题。

首先，我想的是软件关于C/S和B/S模式的争议。曾经也为有B/S模式而开心，但是经过几个B/S程序开发后，才发现B/S是那么的不成熟。B/S所能解决就是客户端的安装和配置，升级问题。所有的软件模块是放置到服务器上完成，但是这样就形成了对服务器的访问量的冲击，几十个客户端还形成不了什么冲击，但是一旦并发量大的时候就不得了，服务器就反应如蜗牛。客户端就根本没有办法动，虽然现在出现了一些减轻服务器交互的更改方法，但还是无法达到C/S所达到的效果。

所以，我一直都是建议采用C/S方式，但是这个C/S方式并不是简单的两层架构，而是多层（》3层）.这样就有效的解决了C/S的一些弱点。这样的结构就必须解决软件安装，配置，升级等一系列问题，否则就会出现维护大的麻烦。
以前基于三层架构的有COM的方法，但是这样的方式最终被微软害得很惨，一次次的补丁升级造成所有的程序需要重新编译后再重新分发是一件非常痛苦的事情。而目前出现的.net就有两种方式去实现：.net remoting和web services.而我个人建议采用remoting模式，因为据我现在查看的资料，web services算是remoting的一个子集，remoting有更加强的扩展功能。

.net remoting的核心就是可以在两个命名空间里面调用类，方法等等。这样就可以让我们在两个程序进行有效的交互。如果一段放在服务器上运行，作为服务，一段在客户机上运行，通过管道进行通信，那么就完成了预期的三层架构。通过服务器端的程序控制，可以让客户端的配置得到控制，这些控制包括升级，配置，权限。而且这样的管道建立方式可以是TCP，也可以是HTTP（虽然http没有tcp方式快，但是却非常适用于局域网）。而采用http方式就可以应用于整个互联网和局域网，真正实现了anywhere。但是其性能如何还没有得到印证。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/54654/viewspace-425480/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/54654/viewspace-425480/