关于网站的架构开发问题

目前看到了一个网站，他分为客户端运行，以及后台维护系统，但是两个系统看起来基本上都是一个B/S结构的两个程序，想了解一下，为什么要这样去设计一个网站？能不能给讲讲基本的设计架构？ --------------------编程问答-------------------- 假设前后台在一个程序里，或者一个前台程序配套5个后台程序，等等，都是可以的。

这就好像小饭馆里，可能一个人又采购又炒菜；但是大一点的饭馆里可能就是将采购和炒菜的人分开了。这个真的看不出什么架构。

架构往往都是应对性能和功能的极端、必须、突然的扩展而作出的重构，你没有确实需要应对那种突变就不需要太注意架构。现在你只应该了解功能、对用户交互界面和访问方式（例如有多少个页面url、分别干什么的、使用几个域名作为功能分离）进行设计。 --------------------编程问答-------------------- 网站的前台，指面向最终用户的部分，偏重于对用户体验、性能的优化。但是相比较而言，其业务是相对简单固定的。
网站的后台，指面向管理员的部分，偏重于实现复杂多变的业务需求。 --------------------编程问答-------------------- 你用过 windows server2008 和　win7 吗？
你可以讲讲这两者的区别吗？

如果你明白这两者的区别，　那网站是一样的 --------------------编程问答-------------------- 除 --------------------编程问答-------------------- 楼主，从实现的角度来看，他们的差别在什么地方那？能不能讲讲？

我的一点简单的理解，是不是客户端网站访问数据库，后台网站也是访问数据库，并修改数据库？他们之间的关联关系是通过数据库实现的？对吗？ --------------------编程问答-------------------- 你可以把一个程序分给不同人去开发，也可以假设用户有着截然不同的两种类型，等等。于是你就可以用不同的进程来服务于它们。

例如一个购票软件，可能有卖票的小程序、核算出报表的小程序、导入可销售的票的小程序，等等多个独立的程序。也可能将多个程序放在一个程序中，明明是一个人只有卖票的职责，他的程序也集成有别的功能。实际上弄成多个小程序、或者一个程序，都是可以的。

数据库系统只是信息的存储。例如我填写一个“购房申请表”，然后交给开发商，你认为我跟开发商的关系仅仅是“随便一张纸”的沟通而跟具体的内容没有关系吗？那我也没有什么办法。

不同的进程访问相同的一个或者多个数据库服务，就好像不同的中国移动用户访问相同的中国移动的路由器系统来交换语音信息、或者获取记账信息一样。如果你满脑子只有这些底层硬件，我也没有办法，而且这也并不重要！

重要地是，设计人员根据最初的某种“直觉”感觉这个系统需要几个子系统，那么就会执行这个开发计划。假设他一开始规划成“1个前台加上5个后台”进程，那么就算是需要集成在一起让他们相互交换数据或者业务服务，也会达到这个目的。而不是仅仅从“一个”数据库出发来考虑架构。 --------------------编程问答-------------------- 设计者会从比较高层次的模型出发去设计所谓的“架构”，而不是纠结于底层有几台服务器、有几个关系数据库系统、有什么其它服务之类的。

设计者会从实用、需求角度去设计系统（但是不是简单地照抄最低级用户的所谓需求）。于是，到底一个网站是一个进程还是6个进程，根本不重要，也不存在技术瓶颈问题。

如果你满脑子就是技术，而不是实用，你就可能很长时间也不理解实用技术，满脑子都是底层技术。与实就会对高级的和实际的系统产生过份的“新奇”。如果你接受了“设计”培训，就不会这么平常的东西而感到新奇了。

补充：.NET技术 ,  ASP.NET