语源科技BlogJava-幻想家

查询无修改的模型处理

Wed, 13 Apr 2011 08:10:00 GMT

在业务中经常把类型给抽象出来作为一个表，这样的表有一个特点就是需要经常查到，但是基本不用修改到。而这种做法很致命的一点就是作为写业务的程序员必须了解数据库的某条记录的编号，然后写进去代码里面，这是完全违反开闭原则的，一旦有修改需要找出所有的代码并修改。

像下面的代码：

1     public static String getFilePath(String fileType) {
2         String filePath = "";
3         Integer type = 57;
4         if (null != fileType && !"".equals(fileType)) {
5             type = Integer.parseInt(fileType);
6         }
7         switch (type) {
8             case 53:
9                 filePath = "userfiles/images";
10                 break;
11             case 54:
12                 filePath = "userfiles/video";
13                 break;
14             case 55:
15                 filePath = "userfiles/audio";
16                 break;
17             case 56:
18                 filePath = "userfiles/document";
19                 break;
20             case 57:
21                 filePath = "userfiles/others";
22                 break;
23             default:
24                 break;
25         }
26         return filePath;
27     }

真正的做法应该是将这些脱离于数据库，保存在文件。好处有

1.查询效率提高N多倍；

2.一旦修改了记录不用修改源代码，而源代码要查找文件，完全符合开闭原则；

3.让程序员更容易理清楚关系，用XML或者其他文件在表示树等结构上面明显有优势；

4.修改记录的成本变得很低，甚至都不用开发一个软件来修改了，只要直接编辑文件就是了（当然不赞成这样，不利于权限管理等）

当然，这样就还有一个问题，程序员需要关注什么。这里建议用工厂模式。

首先建立一个抽象工厂封装，将几种产品的调用做个封装，对外提供一个方法，这个方法只需要一个“类型参数”。就按照上面的例子，可以对外提供images，video，audio等几个类型参数，所有程序员编程的时候就按照这个分类写代码，调用封装类以后在进行switch条件分支处理。

具体代码写多了烦，不写了。

森 2011-04-13 16:10 发表评论

Grails入门1

Mon, 11 Apr 2011 11:42:00 GMT

1. 用NetBeans作为开发工具，安装了Groovy之后就能够开发Grails程序，新建一个Grails程序“addrBook”，如图

2. 配置

配置文件不再是XML，因为在Groovy看来，groovy文件不一定就是要编译的文件，打开几个来看发现其形式结构跟json格式类似。

就目前所知，BootStrap.groovy是启动时要运行的一些脚本。（命名因为遵从“约定优于配置”，所以看不到关于配置启动顺序的文件）。

BuildConfig.groovy是配置生成项目的信息，在里面发现了类似Maven的术语“依赖（dependencies）”。

Config是全局的配置，包括文件编码，文件的存取规则，发布地址和访问地址等等。

DataSource.groovy是配置数据源的，跟spring的DataSource类似，有关于数据库的信息和缓存的配置就在这里。

UrlMappings.groovy是URL和MVC的映射规则描述文件，因为在GSP文件中配置一个链接是很灵活的采用g:link，而controller需要将页面a标签的具体访问地址按照规则映射到对应的控制器上面，所以有定义这个规则的必要。

3. 控制器、领域模型和消息

很明显可以看出Grails风格是三层架构：领域模型-服务-控制器

消息包：是国际化（I18N）的配置，其中最后一个反黑的就是中文。

域类：ORM的模型类，在Grails中占很大一部分，因为弱化了数据库的作用，在数据存储方面完全由领域模型来定义，这让程序员能更好的发挥OO思想。

服务：其实并不作为Grails的中间层，如果按照Grails默认架构方法，用命令行grails generate-all XXX的方法生成一套流程的话，可以发现是没有服务层的，有控制器直接控制对域模型的操作。

控制器：根据Grails的方法已经能生成大量的可用方法，当然还得根据自己的实际需要对该类进行修改。

4. 其他

标记库：各种taglib

实用程序类：可以放各种工具，比方说自动测试，数据生成，jetty服务器启动等等工具类

视图和布局：当用generate的时候自动生成的页面文件就在这个目录下

库：引用的除了Grails之外的库，比如数据库驱动等

脚本：目前还不知道这个脚本指的是本地系统的运行脚本还是Groovy脚本

Groovy源包和Java源包：这里是Groovy项目的风格，在Groovy项目中一般将Groovy和Java的源文件分开两个源文件夹

target：类似Maven生成最终程序的目录，里面存放着程序运行以后生成的二进制文件和日志文件。估计最终打包也是在这个目录下。

集成测试和单元测试：都是放测试类的文件夹，没做过测试不了解。

Web应用程序：应用程序的根目录。

森 2011-04-11 19:42 发表评论

Java集合类

Sun, 27 Mar 2011 04:56:00 GMT

关于Java集合类的文章介绍不少了，这里给个链接，还有上个图。

http://blog.csdn.net/softwave/archive/2009/05/11/4166598.aspx

Collection

Map

森 2011-03-27 12:56 发表评论