网站架构的设计案.doc

网站架构的设计方案 网站架构，一般认为是根据客户需求分析的结果，准确定位网站目标群体，设定网站整体架构，规划、设计网站栏目及其内容，制定网站开发流程及顺序，以最大限度地进行高效资源分配与管理的设计。其内容有程序架构，呈现架构，和信息架构三种表现。而步骤主要分为硬架构和软架构两步程序。网络架构是现代网络学习和发展的一个必须的基础技术。在选择机房的时候，根据网站用户的地域分布，可以选择网通或电信机房，但更多时候，可能双线机房才是合适的。越大的城市，机房价格越贵，从成本的角度看可以在一些中小城市托管服务器，比如说北京的公司可以考虑把服务器托管在天津，廊坊等地，不是特别远，但是价格会便宜很多。现在的PHP框架有很多选择，比如：CakePHP，Symfony，Zend Framework等等，至于应该使用哪一个并没有唯一的答案，要根据Team里团队成员对各个框架的了解程度而定。很多时候，即使没有使用框架，一样能 写出好的程序来，比如Flickr据说就是用Pear+Smarty这样的类库写出来的，所以，是否用框架，用什么框架，一般不是最重要的，重要的是我们 的编程思想里要有框架的意识。网站规模到了一定的程度之后，代码里各种逻辑纠缠在一起，会给维护和扩展带来巨大的障碍，这时我们的解决方式其实很简单，那就是重构，将逻辑进行分层。通常，自上而下可以分为表现层，应用层，领域层，持久层。所谓表现层，并不仅仅就指模板，它的范围要更广一些，所有和表现相关的逻辑都应该被纳入表现层的范畴。比如说某处的字体要显示为红色，某处的开头要空两格，这些都属于表现层。很多时候，我们容易犯的错误就是把本属于表现层的逻辑放到了其他层面去完成，这里说一个很常见的例子：我们在列表页显示文章标题的时候，都会设定一个最大字数，一旦标题长度超过了这个限制，就截断，并在后面显示“..”，这就是最典型的表现层逻辑，但是实际情况，有很多程序员都是在非表现层代码里完成数据的获取和截断，然后赋值给表现层模板，这样的代码最直接的缺点就是同样一段数据，在这个页面我可能想显示前10个字，再另一个页面我可能想显示前15个字，而一旦我们在程序里固化了这个字数，也就丧失了可移植性。正确的做法是应该做一个视图助手之类的程序来专门处理此类逻辑，比如说：Smarty里的truncate就属于这样的视图助手（不过它那个实现不适合中文）。所谓应用层，它的主要作用是定义用户可以做什么，并把操作结果反馈给表现层。至于如何做，通常不是它的职责范围（而是领域层的职责范围），它会通过委派把如何做的工作交给领域层去处理。在使用MVC架构的网站中，我们可以看到类似下面这样的URL： domain/articles/view/123，其内部编码实现，一般就是一个Articles控制器类，里面有一个view方法，这就是一 个典型的应用层操作，因为它定义了用户可以做一个查看的动作。在MVC架构中，有一个准则是这么说的：Rich Model Is Good。言外之意，就是Controller要保持“瘦”一些比较好，进而说明应用层要尽量简单，不要包括涉及领域内容的逻辑。所谓领域层，最直接的解释就是包含领域逻辑的层。它是一个软件的灵魂所在。先来看看什么叫领域逻辑，简单的说，具有明确的领域概念的逻辑就是领域逻辑，比如我们在ATM机上取钱，过程大致是这样的：插入银联卡，输入密码，输入取款金额，确定，拿钱，然后ATM吐出一个交易凭条。在这个过程中，银联卡 在ATM机器里完成钱从帐户上划拨的过程就是一个领域逻辑，因为取钱在银行中是一个明确的领域概念，而ATM机吐出一个交易凭条则不是领域逻辑，而仅是一 个应用逻辑，因为吐出交易凭条并不是银行中一个明确的领域概念，只是一种技术手段，对应的，我们取钱后不吐交易凭条，而发送一条提醒短信也是可能的，但并 不是一定如此，如果在实际情况中，我们要求取款后必须吐出交易凭条，也就是说吐出交易凭条已经和取款紧密结合，那么你也可以把吐出交易凭条看作是领域逻辑 的一部分，一切都以问题的具体情况而定。在Eric那本经典的领域驱动设计中，把领域层分为了五种基本元素：实体，值对象，服务，工厂，仓储。具体可以参 阅书中的介绍。领域层最常犯的错误就是把本应属于领域层的逻辑泄露到了其他层次，比如说在一个CMS系统，对热门文章的定义是这样的：每天被浏览的次数多 于1000次，被评论的次数多于100次，这样的文章就是热门文章。对于一个CMS来说，热门文章这个词无疑是一个重要的领域概念，那么我们如何实现这个 逻辑的设计的？你可能会给出类似下面的代码：“SELECT ... FROM ... WHERE 浏览 1000 AND 评论 100”，没错，这是最简单的实现方式，但是这里需要注意的是“每天被浏览的次数多于1000次，被评论的次数