05 2013 档案
摘要：昨天去面试,面试官提出一个问题,需求大概这样. 有几个监控设备,我们要监控这些数据保存到数据库,同时如果这些数据有异常的话,要及时通知相关人. 一开始我想到的是,做一个服务去扫那些数据,如果有异常,我们就发通知过去. 但给面试官否则了,它说那个通知要实时性的.所以我马上就想到,我们要在原始数据采取中下手,但当时现场也没有很好的模式出来,回来后,我就觉的用下面的设计去做,应该是比较完美的.这样可以极大对代码进行解耦. 请看类图:详细说明如下:提取封装成一个接口,因为不同的设备可能 有不同的提取方式.然后我们接口的基础上实现一个抽象类,这样做目的,就是把给这个提取类的公共功能,写在这个抽象类里面.
阅读全文
摘要：到底什么样的框架才是好框架呢?或许不同人有不同的看法.我个人觉一个好的框架,最重要的要是简单实用,能快速适开发,可维护性高(不会出现复制黏贴的代码),并能快速响应各种业务场景的变化的框架,同时性能不会太差.我觉的这样的框架,就是一个好的框架.而且,我觉的做框架,千万不能设计过度,不然会得不偿失.最关键要看你的业务场景,千万不要因为模式而模式,更多的看考虑它的实用性. 就像我接触的我们公司一个基于EF的三层,架构,我就觉得里面有一些不好的设计.主要表现如下.每个类的一些基本的操作,如增加修改,删除.都是通过代码生成器生成的.其实我是很反对用代码生成器的.用代码生成的代码,就相当于我们在写代码中.
阅读全文
摘要：关于面向对象的原则,相信大家都很清楚.但真正使用时,我想我们都会违反一些原则,因为要遵守这些原则,我们必须要多写好多代码.最后得不尝试. 下面我就关于这些原则发表一下个人的看法:一、单一职责原则 就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。 这个很重要 ,我在程序开发中都会遵守这个原则.二、“开一闭”原则讲的是：一个软件实体应当对扩展开放，对修改关闭。 这个规则说的是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。 从另外一个角度讲，就是所谓的“对..
阅读全文
摘要：我今天,为什么会提出这个问题.因为在做过的项目中,有2个大项目,发现性能瓶颈都是出现在数据库上. 当然这瓶颈出现在数据库上,也有一部分原因是我们一些开发人员,在开发的时候,写的语句有一定的问题. 但除了这些外,我们也确实发现,数据库这一块是我们的瓶颈来的,我们的应用程序有用F5负载均衡,但数据库没有做负载均衡.因为微软的数据库并没有实现负载均衡,而用第三方的,也不是很放心.其实解决这个数据库瓶颈,也是有几个方面可做.是使用缓存,把一些常用的,数据变化不大的数据放在缓存里面,这个我们当时在做优化的时候也有做,效果还是可以的.是把数据库分到不同的服务器上.我们当时才用的是多数据库的方式.然而遗憾.
阅读全文
