xyjikl

项目是别人写的，领导让我们重构。虽然有MVP和MVVM，但领导用了三层架构（表现层，业务层，数据访问层）+MVC这么多年，敲定还是按这种体系。领导负责定基调，具体的实施当然由我们这些人做。于是大体上会把acvitivy/fragment拆一下，主要做controller控制器，view会从里面拆出来单独成一部分，通过接口与activity交互。然后加上实体等部分。大致形成v

在没学习三层之前，我的“今目标”中的项目名称是MVC分层。有一段时间我搞不清这两个是什么概念，有何不同，我找了一些资料，现在还不能很好地理解。先分享一下。三层架构是界面层（UI）、业务逻辑层（BLL）、数据访问层（DAL）构成的，而MVC是模型层（M）、界面层（View）、控制层（Controller）构成的，而且它们之间也不对应。如果硬要给他们对应的话，那么三层架构中的UI对应MVC中的

分层思想的一个核心就是部件化，各个层之间是相互独立的，每一层可以随便抽取换成一个其他语言的版本，但只要与相应的接口吻合就行。我用的三层架构大致是这样的，基本的三层就不说了，然后分别为业务逻辑层和数据访问层定义一个接口，由具体的那个层来实现，问题产生了，由谁来指定程序使用哪个具体的对象来实现相应接口？为解决这个问题，我应用的是抽象工厂模式。分别为业务逻辑层和数据访问层添加一个抽象工厂

开篇笔者用过django一段时间了，是时候做点笔记了。不过官网文档稍微有点复杂，对新手而言很困难， 而网上的一些教程很多都过时了。 最近看到一个外文的教程非常不错， 网址是：http://tutorial.djangogirls.org/， 这个是基于最新的django1.7写的，通俗易懂，非常适合新手入门。 那么我自己参考这个整理了一下这个教程，同时还将源码上传到GitHub上去了。

在Java和C#的编程世界里，并没有出现像C++那样的多脉继承，它们只支持单一的继承，或者多级继承，这一变化最大的影响，我觉得是大大的降低了编程的难度，因为没有了C++的多级多脉继承，所以接口出现了，它支持多重继承，当然它的主要目的是为了实现解耦，将定义与实现分离。今天就来谈谈我对Java中面向接口编程的看法，以及个人的一些改进。先看下面一段简短的代码，publ

前言确实好久没有写过了，一直以来把写博文当作自己学习的总结，当作做过的笔记，随时都可以拿出来看看。不过最近习惯了用OneNote和印象笔记，所以就很少在论坛写博文。但是偶尔看到几篇被转载了，也小小的虚荣了下。这种虚荣大神们已经习以为常，他们是不能理解的。好吧，转入正题。参加工作从事Java Web开发将近两年，也没有完整的搭建出一个SSH框架的项目，说出来确实有点不好意

App.Config【应用程序配置文件】，它其实就是一个标准的XML文件，不过.Net类库已经封装了读取这个文件的方法。可以很方便的使用。看下使用过程。1.右键解决方案资源管理器中你的项目名，【添加】>【新建项】,选择列表中的【应用程序配置文件】，默认文件即是App.Config。确定。2.打开App.Config,初始的XML代码为： 以下面的格式来设置你的

一：三层构架的基础知识在项目开发的过程中，有时把整个项目分为三层架构，其中包括：表示层(UI)、业务逻辑层(BLL)和数据访 问层(DAL)。三层的作用分别如下：  表示层：为用户提供交互操作界面，这一点不论是对于Web还是WinForm都是如此，就是用户界面操作 。我们网站展示给用户看的界面。  业务逻辑层：负责关键业务的处理和数据的传递。

App.Config详解应用程序配置文件是标准的 XML 文件，XML 标记和属性是区分大小写的。它是可以按需要更改的，开发人员可以使用配置文件来更改设置，而不必重编译应用程序。配置文件的根节点是configuration。我们经常访问的是appSettings，它是由.Net预定义配置节。我们经常使用的配置文件的架构是象下面的形式。先大概有个印象，通过后面的实例会有一个比较清楚的认识

为了满足“开闭原则”，大部分设计模式都引入了抽象层，如工厂方法模式、抽象工厂模式、适配器模式、桥接模式、命令模式、策略模式等等。客户端代码针对抽象层编程，而在程序运行的时候再指定其子类，根据“里氏代换原则”和面向对象的多态性，子类对象在运行时将覆盖父类对象。如果需要对系统进行扩展或修改，只需修改子类类名即可。在具体实现时，通过引入配置文件可以使得用户在不修改任何客户端代码的前提下增加或替换子类，其

准备工作：下载整合过程中需要的包http://115.com/lb/5lbxlk60#lib.rar 115网盘礼包码：5lbxlk601.建立web项目打开MyEclipse，我用的是8.6，项目名称就叫ssh好了，注意把项目语言统一设成utf-8。完成之后的项目结构为：2.把该加的包复制到项目里找到项目所在文件

一：添加三框架jar包 二：model层(student.java)    Java代码  package com.wdpc.ss2h.model;    public class Student {      private String id;      private String userName;//创建姓名      pr

工厂设计模式是所有设计模式中最简单的设计模式！！！（就是通过工厂来创建一些对象）工厂模式的典型应用场景：创建对象（当我们感觉到创建对象是件很痛苦的事，会用工厂模式） 工厂模式：简单工厂，工厂方法，抽象工厂（要支持创建多个产品，定义一个抽象工厂，抽象工厂中有多个工厂方法，可以创建多个产品）工厂方法：抽象工厂：利用工厂方法实现抽象工厂

1.概况说明2.猫狗大战举例3.说明为什么要针对接口编程，优点4.说明为什么要“依赖抽象，不要依赖具体类”5.说明“依赖倒置”与抽象工厂模式6.说明“将组件的配置与使用分离”7.简单说明依赖注入8.讲解petshop依赖注入与它的工厂模式9.讲解TheBeerHouse依赖注入形式10.几个.Net的依赖注入容器11.取舍与适用概况说明 

第一遍学习设计模式时,总有飘飘然的感觉.《大话设计模式》这本书虽然读起来挺有趣味，也感觉比其他讲设计模式的书好理解一些。但是真要用在机房收费系统时还是费劲的。米老师讲过：思想要上移，行动要下移。这两点要紧密结合，缺一不可。总在思想层面上绕，比如设计模式中所举的生活中的例子，用在代码中却不是那么容易，所以必须要行动下移，认真实践。而总在代码中绕，不进行总结提炼概括，学习就很局限，所以我们也要不断总结

Table of Contents1 设计模式中的开闭原则1.1 基本原则2 模式中的开-闭原则2.1 策略模式2.2 简单工厂2.3 工厂方法2.4 抽象工厂2.5 建造者模式2.6 桥梁模式2.7 外观模式2.8 中介模式2.9 迭代子模式1 设计模式中的开闭原则 1.1 基本原则系统的可扩展性由开-闭原则、里氏代

工厂方法模式与IoC/DI IoC——Inversion of Control  控制反转 DI——Dependency Injection   依赖注入1：如何理解IoC/DI        要想理解上面两个概念，就必须搞清楚如下的问题：参与者都有谁？依赖：谁依赖于谁？为什么需要依赖？ 注入：谁注入于谁？到底注入什么？控制反转：谁控制谁？控制什么？为何叫反转（

不知道大家还记不记得当年程杰的《大话设计模式》了，最近一直想搞明白控制反转到底是怎么回事，刚刚觉得高大上了一点，然后再进一步去学习去对比的时候才发现，以前早就接触过这类的思想，设计原则的依赖倒转和设计模式的工厂方法都很好的体现了这种思想，迫不及待的想要跟大家分享一下啦！ 一、依赖倒转原则A.高层模块不应该依赖低层模块。两个都应该依赖于抽象。B.抽象不应该

工厂模式也用了不少，特别是MS的petshop中对数据库的访问，通过工厂模式可以达到自由切换SQL 和 Oracle 数据库。近来也在看设计模式的书，发现工厂模式还是有不少的扩展。结合书中的知识和我自己理解，从代码的角度来比较工厂模式各变种。1：简单工厂模式：其作用是实例化对象而不需要客户了解这个对象属于那个具体的子类。using System;using System.Col

在简单的三层登陆完成之后,我又在其中加入了设计模式,其中包括抽象工厂+反射和外观模式.关于设计模式,在学习三层之前我们已经系统的学习过,可是在这次往机房收费系统中加设计模式时,还是感觉无从下手,出现了学没有致用的尴尬情景.不过这也体现了我们提高班学习中项目驱动的优势.　　　接下来是我的一些现有思路,可能还不很准确,期待读者朋友的指点.　　　先说一下简单的三层登陆思想吧:　　

本文的作者Danny hui似乎是TTS上的新人，我从Google搜不出一点关于本人的信息。从通过本文可以看出他对模式与IoC有自己独到的见解，本文在TTS上引发很多网友回帖，反响不一。那么我们现在来看看作者的IoC之路吧。  原文：http://www.theserverside.com/tt/articles/article.tss?l=InjectionwithAbstractFac

一般情况下软件应该尽量遵循以下的设计原则: 开闭原则(OCP)  对扩展开放,对修改关闭里氏替换原则(LSP)  任何类出现的地方,子类一定可以出现(is-a)依赖倒转原则(DIP)  尽量依赖抽象,不要依赖具体接口隔离原则  接口尽量小,不要提供大的接口,使通信尽可能窄合成复用原则  尽量采用合成和聚合的方式达到利用,而不要

写在前面最近一段时间在研究有关设计模式方面的文章，拜读了TerryLee以及吕震宇两位老师所写的设计模式方面的系列文章，收获颇丰，也让我对OOP，OOD有了新的理解和认识，不过在看到工厂方面的几篇文章时，却总有个地方想不通，望各位老师专家能替在下答疑解惑，以下是自己对工厂模式的一些理解以及提出的一种改良方案，不知道是否有人提出过类似的方案，如有雷同纯属巧合。有说得不对的地方还请批评指正。 

利用抽象工厂创建DAO、利用依赖注入去除客户端对工厂的直接依赖、将有关Article的各种Servlet全部封装到一个Servlet中（通过BaseServlet来进行ArticleServlet方法的导向）（这篇文章中只总结了ArticleServlet，而并没有分析ChannelServlet，两者其实差不多，关于ArticleServlet的基本都可以用于ChannelServlet

在我的上一篇文章(疑惑？改良？从简单工厂到工厂方法)中，详细论述了创建模式中简单工厂到工厂方法的演变过程，并试图结合工厂方法的设计以及.net中的反射机制之所长，改良出一种新型的工厂—反射工厂，这当然不是我的首创，经典的PetShop 中便有此工厂的身影。本文尝试按照前篇文章的思路，借着工厂方法到抽象工厂的演变过程而继续对抽象工厂进行改良，文章中的思想仅代表了作者当时的观点，有欠妥的地方，还请

《大话设计模式》中第15章中《就不能不换DB吗？》引出了我今天要谈论的主题：抽象工厂+反射+配置文件 实现数据访问程序。当时也不甚理解啊！到了机房收费的亲身实践中，终于体会到了这对组合的奥秘。抽象工厂模式（Abstract Factory）提供一个创建一系列相关或相互依赖对象的接口，而无需制定它们具体的类。知道它是用来创建工厂的就OK了。反射提供了封装程

工厂模式也用了不少，特别是MS的petshop中对数据库的访问，通过工厂模式可以达到自由切换SQL 和 Oracle 数据库。近来也在看设计模式的书，发现工厂模式还是有不少的扩展。结合书中的知识和我自己理解，从代码的角度来比较工厂模式各变种。1：简单工厂模式：其作用是实例化对象而不需要客户了解这个对象属于那个具体的子类。using System;using System.Col

（一）工厂模式从一个例子开始讲起：首先我们建立一个Chinese.java类，该类的sayHelloWorld(String name)方法，用中文对名为name的人问好，其内容如下：     [java] view plaincopyprint?public class Chinese {      /**-- 用中文对

IOC实现：IOC容器我们仅仅停留在知道上是不行的，我们要动手做印象对更深刻，那么我给大家看一个代码，看看代码中IOC容器的实现。代码实现：创建一个类库：解决方案的类库建立：创建一个实体类：User：[csharp] view plainc

－转载下面是作者对设计模式的理解并自以为所对应的实例一 ： 单例模式(Singleton) 账本类：1 单一实例 2 给多个对象共享 3 自己创建。网页计数器    二：策略模式(Strategy)   使用QQ泡MM时使用外挂  客户端 ：ME 抽象类： 外挂 具体：策略（图片，笑话，名人名言）图书销售算法（不同书本折扣的算法） 三：原型模式(Pr

C#版的三层登陆实例，只是为了学习三层而实现的。为了接下来需要进行的vb.net版机房收费系统。根据上次的C#改编的vb.net版本登陆实例。不过在验收的时候发现了很多问题，所以进行了修改。   花费好几天的时间，终于从C#转化成了vb.net版本。期间参考了一些师哥师姐的博客来理解三层是如何交互的。起初上一篇实例，并不是很懂，只是理解了个大概。然后根据那么多材料来进行对比。终于看懂他们是

创建web工程，使用Hibernate的时候，在工程里一个一个创建实体类太麻烦，浪费时间，现在教大家如何用MyEclipse自动生成Hibernate映射文件及实体类方法/步骤1创建数据库，创建相应的表2点击图标，选择MyEclipse Datebase Explorer3右击空白区域，

浅析三层架构与MVC模式的区别 三层架构介绍:（点击链接即可见三层架构）  MVC模式介绍：MVC全名是Model ViewController，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用于组织代码用一种业务逻辑和数据显示分离的方法，这个方法的假设前提是如果业务逻辑被聚集到一个部件里面，而且界面和用户围绕数据的

最近因为学习三层架构中的实体类，引发不少问题，下面具体说下三层中的实体类，即数据库表的映射 为何使用实体类？  数据库中DatsSet 不具备OO的优点， 实现数据检索繁琐，易出错， 使数据结构暴露在业务逻辑层和表现层为了消除以上局限我们使用实体类  举例说明 用实体类之后，代码时变得简介，面向对象封装思想。最重要的是，如果将来有所改动，

三层架构实例一、新建立一个三层架构体系结构解决方案新建一个空白解决方案。然后：     1.“添加”－“新建项目”－“Visual C#”－“类库”－“称:LoginBLL”－“业务逻辑”（业务层，下简称B层）如下图： 2.“添加”－“新建项目”－“Visual C#”－“类库”－“名称:LoginDAL”－“数据访问”（数据层，下简称D层）如下图：

机房收费系统vb.net个人版已完成，在此过程中分层的好处在系统的完成过程中得到了很好的体会。第一遍用的是纯三层做的，这几天又在此基础上又重构了登录的demo,加上抽象工厂和配置文件的使用。下面以登录功能为例，总结一下我的机房收费系统。一、下面看一下我的包图：       可以看到，这张图是从最基本的三层UI→BLL→DAL加入设计模式（抽象工厂）演化而来的，采用抽象工厂是考虑到日

很早之前，就听说过三层结构了。当时只知道 三层结构 是把 系统的 界面  跟 数据库操作等不相关的程序分别开来。原来这么简单的实现，确实传说中的 三层结构啊。    首先，先来看一下是哪三层。表示层（UI，User Interface），业务逻辑层（BLL BusinessLogicLayer），数据访问层（DAL Data Access Layer）。三层的划分是物理上的划分。   

最近因为三层架构中的实体类，引发了不少小问题，下面列举一下，谈谈自己的感想。         本文所指的实体类仅限于三层中的实体类，即数据库表的映射。 一、为什么要用实体类？          |  使程序简洁易懂，便于维护。         |  暗合接口不变原则。         |  体现面向对象思想。         举例说明：         

一、概要在我的上一篇博客中，我们谈了谈分层，到底为什么分层（http://blog.youkuaiyun.com/shan9liang/article/details/6836300）这篇博客，准备用一个小Demo来介绍应该实现三层架构。三层架构只是分层的一种经典形式，到底分几层，要依具体情况而定，考虑到系统的复杂程度，和后期的可维护性，完全可以分四层，五层，甚至六层，七层。 三层架构(3-t

使用Struts2或webwork2有一段时间了，想把Struts2框架的思路简单的与大家分享一下，之前我是看过Struts2源代码的，所以本文算是它的一个功能非常有限的压缩版本。我也不打算重复发明轮子，只想让Struts2或Webwork2的新手更多的了解框架本身，而不仅仅是应用。废话少说，开始吧。  本文采用基本Xml来配置Action，如果有时间会继续写Annotat