上一页 1 ··· 5 6 7 8 9 10 11 12 13 ··· 19 下一页
摘要: 经过上面篇文章的介绍,整个系统的框架算是基本搭建完了,下面,我们要具体实现各个层次。关于数据访问层的实现,我准备讨论三种实现方式,这一篇文章讨论第一种:Access+动态生成SQL。 顾名思义,这种实现将使用Access作为后台数据库,而操作方式也是最基本的使用SQL命令。 在具体编写实现代码之前,我们需要做一些准备工作: 第一步,我们要将Access数据库搭建完成,具体做法如下。 在Web工程下新建一个文件夹,命名为AccessData,并在其中新建一个mdb文件(即Access数据库文件),按照前面介绍过的数据库设计构架,将数据表及表间关系建好,这里不再赘述。 第二步,我们要进行一些配置。 阅读全文
posted @ 2011-03-26 21:23 似水流年-johnhuo 阅读(195) 评论(0) 推荐(0) 编辑
摘要: 我们设计的分层架构,层与层之间应该是松散耦合的。因为是单向单一调用,所以,这里的“松散耦合”实际是指上层类不能具体依赖于下层类,而应该依赖于下层提供的一个接口。这样,上层类不能直接实例化下层中的类,而只持有接口,至于接口所指变量最终究竟是哪一个类,则由依赖注入机制决定。 之所以这样做,是为了实现层与层之间的“可替换”式设计,例如,现在需要换一种方式实现数据访问层,只要这个实现遵循了前面定义的数据访问层接口,业务逻辑层和表示层不需要做任何改动,只需要改一下配置文件系统即可正常运行。另外,基于这种结构的系统,还可以实现并行开发。即不同开发人员可以专注于自己的层次,只有接口被定义好了,开发出来的东西 阅读全文
posted @ 2011-03-26 21:16 似水流年-johnhuo 阅读(191) 评论(0) 推荐(0) 编辑
摘要: 接下来,将进行接口的设计。这里包括数据访问层接口和业务逻辑层接口。在分层架构中,接口扮演着非常重要的角色,它不但直接决定了各层中的各个操作类需要实现何种操作,而且它明确了各个层次的职责。接口也是系统实现依赖注入机制不可缺少的部分。 本项目的接口设计将按如下顺序进行: 1.首先由前文的需求分析,列出主要的UI部分。 2.分析各个UI需要什么业务逻辑支持,从而确定业务逻辑层接口。 3.分析业务逻辑层接口需要何种数据访问操作,从而确定数据访问层接口。 另外,为保证完全的面向对象特性,接口之间的数据传递主要靠实体类或实体类集合,禁止使用DataTable等对象传递数据。 由需求分析,列出主要UI 需求 阅读全文
posted @ 2011-03-26 21:15 似水流年-johnhuo 阅读(189) 评论(0) 推荐(0) 编辑
摘要: 实体类是现实实体在计算机中的表示。它贯穿于整个架构,负担着在各层次及模块间传递数据的职责。一般来说,实体类可以分为“贫血实体类”和“充血实体类”,前者仅仅保存实体的属性,而后者还包含一些实体间的关系与逻辑。我们在这个Demo中用的实体类将是“贫血实体类”。 大多情况下,实体类和数据库中的表(这里指实体表,不包括表示多对多对应的关系表)是一一对应的,但这并不是一个限制,在复杂的数据库设计中,有可能出现一个实体类对应多个表,或者交叉对应的情况。在本文的Demo中,实体类和表是一一对应的,并且实体类中的属性和表中的字段也是对应的。 在看实体类的代码前,先看一下系统的工程结构。附件: f3.jpg 如 阅读全文
posted @ 2011-03-26 21:11 似水流年-johnhuo 阅读(249) 评论(0) 推荐(0) 编辑
摘要: 本文主要是对将要实现的架构进行一个总体的描述,使朋友们对这个架构有个宏观上的认识。这篇文章理论性的东西会偏多一点,从下篇开始,将进行实际项目的开发。这篇文章的许多内容摘自我的毕业论文。架构基本原则: 这里,将描述一些在这个架构设计中的基本原则,其中很多都是经典的设计原则,不过针对分层架构的特点,用我自己的语言进行了描述。其中也有我自己提出的原则。 逐层调用原则及单向调用原则 现在约定将N层架构的各层依次编号为1、2、…、K、…、N-1、N,其中层的编号越大,则越处在上层。那么,我们设计的架构应该满足以下两个原则: 1.第K(1<K<=N)层只准依赖第K-1层,而不可依赖其他底层。 阅读全文
posted @ 2011-03-26 21:09 似水流年-johnhuo 阅读(264) 评论(0) 推荐(0) 编辑
摘要: 在实际的项目中,需求分析和数据库的设计是很重要的一个环节,这个环节会直接影响项目的开发过程和质量。实际中,这个环节不但需要系统分析师、软件工程师等计算机方面的专家,还需要相关领域的领域专家参与才能完成。 但是,在这个文章系列中,所要使用的Demo仅仅是一个例子,而且其业务极为简单,因此,这里并不是真正的需求分析和数据库设计,而是将Demo的需求和数据库罗列至此,使朋友们对Demo有一个大体的了解,方便后续文章中开发过程的理解。需求分析: 这个项目是一个留言本,其业务极为简单,现将其描述如下。 1.任何访问者可以进行留言,留言完成后,不会立即显示正文,而是要经过管理员验证后才可显示。 2.任何访 阅读全文
posted @ 2011-03-26 21:08 似水流年-johnhuo 阅读(164) 评论(0) 推荐(0) 编辑
摘要: 通过浏览博客园的文章发现,很多朋友对分层架构特别感兴趣,刚好我刚做完的毕业设计就是专门研究.NET平台上分层架构的(题目叫“基于.NET平台的分层架构与设计模式应用研究”)。通过做这篇论文,我对分层架构有了一定的了解,所以,就萌发了想写一个文章系列,详述一下分层架构。然而,论文的理论性太强,不适合在网上发布,尤其不适合初学者理解,所以,我想在这个文章系列中,少讲理论,而是通过做一个完整的案例来讨论分层架构的基本方法,这样会直观很多。希望在这个文章系列的写作过程中,能和朋友们一起学习,一起进步。 为了让朋友们把主要精力放在理解分层架构而不是案例本身,我准备选择一个相对简单的留言本系统作为Demo 阅读全文
posted @ 2011-03-26 21:06 似水流年-johnhuo 阅读(169) 评论(0) 推荐(0) 编辑
摘要: 上篇我们简单的了解了AOP的应用场景,知道AOP编程的重要性。这篇我们先看一段代码,来开始今天的学习。 回顾与上篇类似的代码:SecurityService类的IsPass判断用户名为“admin”则有权限保存数据。OrderService为保存数据的类,实现IOrderService接口。 public class SecurityService { public bool IsPass(string userName) { return userName == "admin"; } } public interface IOrderService { string Us 阅读全文
posted @ 2011-03-26 21:03 似水流年-johnhuo 阅读(160) 评论(0) 推荐(0) 编辑
摘要: AOP即面向切面编程(Aspect Oriented Programming的缩写),是OOP(面向对象编程)的一种延续形式。是通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术,它从一个不同于OOP的角度来看待程序的结构:OOP将应用程序分解为一系列表现为继承关系的对象;AOP 则把程序分解为一系列方面(aspects)或者关注点(concerns)。AOP将诸如事务管理等本来横向分布在多个对象中的关注点进行了模块化处理(这些关注点也常称为横切(crosscutting)关注点)。在Spring.NET中提供了面向切面编程的丰富支持,允许通过分离应用的业 阅读全文
posted @ 2011-03-26 21:00 似水流年-johnhuo 阅读(206) 评论(0) 推荐(0) 编辑
摘要: Spring.NET通过几个专门的接口来控制容器中对象的行为。说到对象的行为无非就要提到对象的生命周期控制。类似在WinForm开发,Form生命周期中,Load方法为Form的载入方法和Dispose方法为Form的销毁方法。Spring.NET都能完美的实现这些需求。 一、生命周期接口 在使用Spring.NET框架的时候通常遇到怎样初始化和销毁非托管资源(如数据库连接)的麻烦,下面的解决方案可能对您有所帮助。 1.初始化行为 继承Spring.Objects.Factory.IInitializingObject接口或者配置object节点的init-method属性,Spring.NE 阅读全文
posted @ 2011-03-26 20:59 似水流年-johnhuo 阅读(200) 评论(0) 推荐(0) 编辑
上一页 1 ··· 5 6 7 8 9 10 11 12 13 ··· 19 下一页