Roy's Blog
go on,go on

也说数据访问工厂的设计,算不算“多余”

roydux,2009年6月13日

但凡有关于.NET的架构设计，都把数据访问层接口作为亮点，把数据访问层提出来了，以后换数据库的时候可以更EASY。

但是，现实的项目中有几个真正换过呢？

     试想把一个项目包给微软做，微软难道肯在项目上留活路给其他数据库？靠微软传教士们滔滔不绝的口才，当然微软是最好的，拿一般的企业项目来说，当然推介.NET + SQL SERVER的方案（话说我也没见过微软做项目，这段我且猜成是这样的吧），什么？你想用其他数据库？为什么不用SQL SERVER？SQL SERVER配合.NET才是极致啊，我们有专业的态度，且为了高效会写高效的存储过程（想换数据库也费劲死你），windows server 2003/8 + .NET + SQL server，我们已经给XX，XX，XX……（此处省略若干公司名）做过成功的项目，你既然选择我们，有理由不相信我们吗？OK，.NET + SQL Server了，话说SQL SERVER已经够优秀了，还有什么必要或理由给其他数据库留接口呢？这不是对SQL SERVER不信任吗？且如果以后承载不了，那我们可以再提供解决方案，做性能调优之类的，这才是大公司的特色嘛！

...

more...

分类: 设计模式 | Tags: | 评论:0

PowerDesigner 15 貌似已经出来了……

roydux,2009年2月18日

发展真快了……感觉12还显新呢，15就出来了，11是太老了，mysql只支持4.0了。

Powerdesigner15试用版地址：http://www.sybase.com/detail?id=1038605（需要打开找下载地址，可能也会让你填写点信息，随便填就OK）

破解文件：http://d.download.csdn.net/down/841486/chc8000（也需要登陆才能下）

...

more...

分类: 设计模式 | Tags: powerdesigner15  pd15   | 评论:0

[转]网站架构收集

roydux,2008年12月3日

转自http://www.hiadmin.com/?p=124

DBA notes上果然好东西很多
许多大型(只是访问量,而不是公司规模)的web 2.0的网站架构
上面都有
现在收集整理一下
这种资料.向来可遇不可求啊

WikiPedia 技术架构学习分享
http://www.dbanotes.net/opensource/wikipedia_arch.html

YouTube 的架构扩展
http://www.dbanotes.net/opensource/youtube_web_arch.html
...

more...

分类: 设计模式 | Tags: | 评论:0

关于项目开发

roydux,2008年4月9日

 

more...

分类: 设计模式 | Tags: | 评论:0

PowerDesigner Name/Code自动调整

roydux,2008年3月19日

大家都清楚在用PowerDesigner的时候,当你输入Name的时候Code是会自动帮你按照Name的内容填上的.
这个功能虽然好用,但是我需要在Name这一项加上一个中文的注释,这个时候怎么办呢?
下面两个例子,相信对你相当有用.
Examples
· Script 1:
.set_value(_First, true, new)
.foreach_part(%Name%, "'#'")
.if (%_First%)
.delete(...

more...

分类: 设计模式 | Tags: powerdesigner   | 评论:0

23种模式趣味解释[转]

roydux,2007年8月1日

创建型模式 

1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说"来四个鸡翅"就行了。麦当劳和肯德基就是生产鸡翅的Factory 

工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 

more...

分类: 设计模式 | Tags: | 评论:0

浅谈贫血模型与胀血模型

roydux,2007年8月1日

今天在项目中看到许多代码都用胀血模型的方法来实现.感觉比较不顺手，因为贫血模型看惯了吧...汗.....
如果以面向对象的眼光来看，其实胀血模型应该算是合理的.但如果项目稍微大点的话，缺点就会显露出来,最简单的是，一个有几十个结点的类,其内部成员与外部接口已占据不小的空间,这时如果再增加繁多的操作接口,会显的很乱.不过这个不是必然的,在内部结构组织合理时,还是能避免这个问题的.
再来谈贫血模型,最初见到贫血模型时,感觉并不是十分符合面向对象的特性.但后来用的多了,发现这其实是面向对象的一种细化.它使功能的访问彼此得到较好的封装.达到较好的松耦合.

在选择开发模型时,如果内部成员较少，逻辑较简单,则用胀血模型可得到良好的效果.如果项目庞大,内部成员巨多，逻辑也较复杂时,建议使用贫血模型,能有较好的条理性.

more...

分类: 设计模式 | Tags: | 评论:0

分页:«1»