为了辅助项目开发任务的分工，也使成员对本身的工作进行明确，了解其他成员的工作情况，以及整个项目的进展和工作量。我苟且根据我所理解的将整个项目的模块进行划分，构建一个指导框架，以供大家参考。
希望大家能提出自己的意见，并在项目进行的过程中不断的修改完善，项目成员按照规范开发，构建相对灵活的系统。
下面是系统的体系架构图，根据分层设计模式，分为经典的三层。
表示层：为了更好指导表示层组的开发，这一层的模块分得比较细。表示层只依赖业务层，表现在ViewControl和WebUtility调用ModuleContrller的方法。业务层的其他细节，表现层并不清楚。
l PageView指的是简单的aspx页面，主要完成页面的布局、文本的显示和功能按钮提供；
l ViewControl是页面对应的cs文件，主要做一些控件与数据的绑定、事件与操作的连接、页面逻辑的判断，通过调用WebUtility或者ModuleController的静态方法。
l WebUtility是ViewControl中部分公用方法的提取，以便更好的进行代码重用，主要是静态方法，通过调用ModuleController完成。
l ASP.NET 2.0(Menu+SitMapPath+Master+Theme+Skin+Wizard+...)指有效地利用ASP.NET 2.0的一些功能，快速的完成表示层工作。
业务逻辑层：感觉有点像MVC模式、这是Model却像是遵循了InformationExpert模式，抛开一些模式，只为更好的表示业务模型，完成业务逻辑。
l ModuleController包含静态方法，通过调用BusinessObjects(Model+Operation)满足表示层的所有需求，包括请求数据，请求操作等，是系统实现业务逻辑的核心部分。
l BusinessObjects(Model+Operation)是系统对业务模型进行建模，包含所有的业务建模对象。每个对象都有本身的特性（字段）和责任（属性、方法）。
数据访问层：将数据库的存储过程StorageProcess和视图View都包含进来，有点别扭，没有松散耦合（高内聚、低耦合）可言。但却能够更好的表示当前我们的任务分工。
l DataAccessController指调用DAAB完成一切数据库访问操作。目前每个业务层的类（实体类和控制器）都对于一个数据库访问器DataAccessController （可能会产生重复劳动，数据库也不好管理，等待进一步改进）。
l DataAccessApplicationBlock(EbterpriseLiberary)是微软企业库的一个数据访问控制模块。
l SQL Server 2005 Database，本系统目前采用了是该数据库，在进行重构之前，绝对没有可能采用其它数据库（重构一定比更换数据库来得更早一些）。
l View和StorageProcess主要为了强调数据访问层，注意编写，以便提高性能和代码简洁性，同时也争取数据库管理的一致性（需要更好更具体的办法）。
下面是各模块（本来应该是包）的依赖情况。本系统没有定义接口，层次与模块之间的交互契约只是通过系统分析文档和静态类图定义注释来代替。请上层主动提出服务需求，下层根据需求完成“接口”实现，系统分析和文档编写人员注意需求的更变。
