YY部分仅供娱乐，请勿拍砖。正文部分，如有错误或不足，欢迎拍砖、指正。
第三章 ： OnePiece—数据库设计
嗯，基本的准备工作也做得差不多了。今天我们就在众神的保佑下来做本系统的数据库设计。 由于“OnePiece”的神力太大，春哥交待过，以我现在的功力是断然不能够一下全部做出来的，心太贪了到时候系统没有做出来，人先废掉了，那才是郁闷啊。所以，春哥叫先做系统的新闻模块，我们就从新闻模块做起吧。说白了也就是做一个传说中的新闻发布系统。
在做这个系统之前先说说我们整个系统的架构吧。系统架构，有我只闻其名的MVC，有多层架构，也有一些其它我还不闻其名的架构，这些方案都有自己的优缺点，如果你很感兴趣的话可以问问神器“Google”，这里我就不多说了，因为事实上我对它们的了解也不多。关于这个系统的开发，我们采用多层架构来开发，为什么要采用多层架构呢？很简单：因为这是目前唯一一个我知其名且勉强能会其意的架构，呃。。。狂吐血中。那么什么是多层架构呢？
多层架构，就是“通过分解业务细节，将不同的功能代码分散开来，更利于系统的设计和开发，同时为可能的变更提供了更小的单元。”（不好意思，我网上找到的一个解释之一，我觉得和我的理解差不多，也就是这个意思，把不同的操作封装在不同的层当中，每个层都只负责自己部分的工作，而不用去当心其它的工作怎么完成。这样就为团队开发提供了方便，我们可以根据计划分开编写代码。当然同时也对系统的模块化和细化也有很大的作用。）下面来一个多层架构的典型图解：
上图是一个典型的三层架构：
１、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
２、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
３、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。
三层架构的优缺点：
优点：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
缺点：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
但是随着软件行业的发展，以及各种系统的业务越来越复杂，传统的三层架构已经有点不能胜任了，于是出现了，在传统的三层架构上发展而来的多层架构：
关于这些理论的东西就说这么多了，因我我也只知道这么点了。呃。。。。。。园里有一篇介绍.Net的三层架构的文章大家可以看看：.Net三层架构
本系统分层：DAL：数据访问层（持久层）；Model：模型层；BLL：业务逻辑层；WebUI：Web界面层；
呃，关于架构就说这么多。现在正式进入数据库设计，前面也说过了，我们先把系统中的新闻模块完成所以数据库的设计也先从新闻模块做起，其它的模块在后续的开发中再来进行设计编写（这在实际开发中显然是不行滴，但是由于我也只是第一次做开发，而且没有外界压力的，所以就先这么做了）
新闻模块的要求，如果忘记了的可以看看前面的系统分析，这里就不多说了。根据系统要求我抽象出了三个类，这三个类也就是我们设计数据库的根据：
NewsCategory类：新闻类别类，由于系统要求新闻类要有层次而且还要可以根据而要进行排序，所以在刚开始设计时其中加入了rank排序值 level所属层 higherCaID上层的ID。写这个的时候才发现，level好像用不着？。。。暂先留在这里把。大概是用不着的了，那就把Level属性去掉。
News类：新闻实体类。我想其中的名字应该可以自释意。所以就不详说了。只说明一点，其中的图片titleImage和newsImages都是采用保存图片路径来保存图片信息的，我也想过另建一个图片表来专门管理图片。不知道哪种方案好就采用了这个方法。你有什么好的建议也可以讲讲哦。
Comment类：新闻评论类。注：user属性后来发现改为UserID比较好，和用户表中的用户ID关联。如果是非注册用户则和用户表中的特定ID关联。
根据类设计出来 的数据库如下图：形成一条链式的关系结构，News的CategoryID与NewsCategory的ID关联、Comment的NewsID与News的ID关联。以表示它们的从属关系。
呃，数据库基本就是这个样子的。以后还会逐步完善。
小小菜鸟没有开发经验，对于本系列开发也没有做什么准备，所以其中不免有错误或遗漏，还请诸位不吝赐教，小弟在此感激不尽。另外，由于在做OnePiece的开发的同时我也在不断的学习和解决当中遇到的问题。所以文章发布的日期间隔或许会有些长，还请各位看官见谅。
下集预告：第四章 ： OnePiece—新闻模块的数据访问层；
本站采用创作共用许可 署名，非商业 欢迎转载，转载请注明出处，并包括此段声明 。 Cat_Lee @ cnblogs