微型项目实践-目录

1. 什么是微型项目 微型项目是指绝大部分工作由一个人员负责的项目,这个核心成员负责项目的系统分析.构架.及绝大部分的编码工作.项目的持续时间一般不会超过一个月.项目的参与人员除了核心的程序员外还可能一部分辅助人员,包括第二程序员(负责一部分编码工作).美工(负责界面设计)等. 微型项目的规模一般很小,业务逻辑也比较简单,价格一般也不会超过10K.程序员通常直接和对方领导打交道.客户大多没有任何技术背景.需要程序员直接负责系统的需求分析. 2. 微型项目分析 2.1 一般流程: 微型项目的流程可

上一篇文章中,我们简单的分析了页面的设计,今天我们来看页面中的动态部分.Master和Default页 面中的主要控件如下表: 控件ID 描述 Calendar Asp.Net自带的日历控件,使用自带的样式,以后我们会使用该控件实现根据日期的查询. ListView_BlogClass ListView,用于显示日志分类.该控件生成的Html全部是连接,不需要响应事件,故 EnableViewState设置为false. ListView_BlogList ListView,用于显示日志.该控件

上一篇中,我们分析了UI层的结构和PageBase类,今天我们把注意力转移到页面中来.下面这个图是 我们系统的最终效果图: 这个当然不是我做的,我也做不出来:), 但是我想大体介绍一下页面的制作流程和一些经验技巧: 需求分析人员分析并确定需要哪些页面.有时候(大部分时候)只考虑首页,因为首页能确定系统的 风格.定下首页其他页面基本上就有着落了. 需求分析人员和客户讨论页面的风格.色调.系统的风格通常是一些形容词,比如简约.明快等.良 好的方式是准备很多图片(网页模板更好)给用户看,让他选,这样可

上一篇中,我们完成了数据库的访问,今天我们来看看系统设计的最后一部分--UI层.加入了UI层 之后,系统设计会变成这个样子: 这也就是系统最终的结构图.这个图上新添加的两个项目,一个是UI,一个是WebSite.其中前者依赖 于业务逻辑和数据访问,提供统一的界面处理,而WebSite仅包含Aspx页面.需要注意的是,上图中箭头 表示依赖或调用,而这个关系是具有传递性的,比如UI依赖于Business,而Business依赖于Common,则UI 自然就依赖于Common. 将UI和WebSite

上一篇中,我们生成了实体代码,加入了Business和Common,项目突然变得大了起来,现在我们就来 一点点分析. 我们还是从这张系统结构图出发.先来看Common这个DLL,其中所包含的类,如下图所示. 1,验证相关类(IValidatable,Validater,ValidateResult,ValidateFailException) 这四个类主要是在业务层,验证实体数据时使用,每一个实体(Entity)在保存数据时对其自身数据 进行验证,以保证绝不让非法数据保存到数据库中,这四个类就是

上一篇文章中,我们分析了系统的两个实体类,并且给出了对应的实体XML.今天我们来看看如何根据 这个XML进行代码生成. 1: <?xml version="1.0" encoding="utf-8" ?> 2: <Entities xmlns="http://it.ouc.edu.cn/EntityDescription/V2"> 3: <Entity title="日志" name="

上一篇中,我们分析了页面中的控件和数据绑定中的扩展方法,今天我们看数据的查询和显示.其中 ,数据的查询属于业务逻辑层(Business),而显示属于UI层. 假设我们要根据以下两个条件进行查询: 日志分类(ID) 发布时间(范围) 两者为"AND"的关系,则查询可以通过通过扩展IQueryable<Blog>类实现,该功能定义在 BlogExtension类中(位于DongBlog.Business\Blogs\Blog.cs文件中),代码如下: 1: /// <su

上一篇文章,我们分析了数据访问是如何定义,以及如何与其它(特别是Business)模块耦合的,今 天我们来看一下数据访问(DataAccess)是如何实现的. 从系统结构图和上一篇"数据访问的定义"中可以知道,数据访问层的任务就是实现 IEntityDataAccess和IDatabase接口.由于Linq的出现,我们只需要一个Adapter,将Linq2Sql的类适配 到IEntityDataAccess就可以了,其类设计图和文件结构如下如下:

上一篇中我们分析了实体类,这一篇我们来看看数据访问是怎么设计的. 从系统结构图中可以看出,到目前为止我们没有任何关于数据库访问的实现部分,而Business则仅仅 是给出了IDatabase和IEntityDataAccess这两个用于定义数据访问要实现什么功能的接口.我们认为数据 访问如何实现是系统的细节,而领域模型(业务逻辑)是抽象,抽象的领域模型定义.但不关心.更不依 赖数据访问和数据库的设计与实现.相反,作为实现的细节,数据层根据业务逻辑的需要实现,随业务逻 辑的变更而变更,这也符合DI