没有你的城市 的个人资料古月文武的资料库照片日志列表更多 ![]() | 帮助 |
|
7月26日 内容管理的七种武器长生剑-内容创建
“长生剑,世上最锋利的剑,剑气威力强大而又持续不断、绵绵不息”。
内容管理离开了内容的创建,就会变成无水之源。无论是新创建的内容还是已经存在的内容,都要以海纳百川的精神一一汲取。经过捕获、转换,变成合适的形式进行存储、管理。有了源源不断的内容,内容管理才可获得长生。
孔雀翎-内容交付
“世界上绝没有一种暗器能比孔雀翎更厉害,也绝没有一种武器能比孔雀翎更美丽……孔雀翎娇小的身躯中隐藏着巨大的威力”。
多渠道、个性化的内容交付方式,能够将内容管理的价值充分展现给用户,良好的用户体验永远是系统的最大威力体现。
碧玉刀-归档
“刀是最容易上手的武器,也是使用最广泛的武器……碧玉刀本身也是实力的象征”。
归档是很常见的操作,但是更加完善归档机制能够让内容管理发挥更大的威力。
多情环-工作流
“多情环是一种奇特的武器。无论套住了什么,立刻就紧紧地缠住,绝不会再脱手,就像多情的恋人一样”。
现在是一个分工协作的时代,内容管理也遵循这一规律。而协作的秩序就要靠工作流程来保证。内容管理需要建立相应的业务规则、策略和过程,就像多情环一样,把内容管理中的各个角色绑在一起,协同工作。
离别钩-版本控制
“离别钩是一件武器,无论钩住人的任何部位,都能造成离别……但使用它的初衷却是为了能够与所爱的人相聚”。
版本控制可以将同一内容的不同阶段分开,通过checkin,checkout的方式进行操作,并在需要时支持版本回退。版本控制的初衷是为了避免冲突。
霸王枪-内容存储
“霸王,力拔山兮气盖世。枪,百兵之祖是为枪……霸王枪是世上最霸道的兵器之一”。
内容的存储是内容管理的核心,内容存储应该与具体的技术无关,不管是文件系统、数据库或其他的技术,不管是内容本身还是内容的元数据,都能够提供良好的支持。这样的内容存储霸气十足,面对任何环境都能够从容应对。
拳头-内容组织
“拳头也是一种武器。而且是无可替代的武器。当分散的五指握成拳头,它的力量又岂仅仅是原来的五倍”。
内容之间往往存在千丝万缕的关联,而对这种关联关系的维护,正是内容管理核心价值的体现。对内容的组织应该灵活,容易扩展。可以任意增加元数据和内容关联。实际上这是信息转化为知识的关键过程。
结束语
内容管理的七种武器,缺一不可。充分发挥每种武器的最大威力,才能让内容管理发挥真正的作用。 7月14日 61条面向对象设计经验(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口,但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。如果类的两个方法有一段公共代码,那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。 (7)类之间应该零耦合,或者只有导出耦合关系。也即,一个类要么同另一个类毫无关系,要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响,则将对包中的所有类产生影响,而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即:互不沟通的行为)。朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类,而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能,也即:按照设计,顶层类应当统一地共享工作。 (13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。 (16)在由同用户界面交互的面向对象模型构成的应用程序中,模型不应该依赖于界面,界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。 (18)从你的设计中去除不需要的类。一般来说,我们会把这个类降级成一个属性。
(19)去除系统外的类。系统外的类的特点是,抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类,特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段,我们常会发现很多代理没有用的,应当去除。
(22)尽量减少类的协作者的数量。一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。
(24)尽量减少类和协作者之间的协作量,也即:减少类和协作者之间传递的不同消息的数量。
(25)尽量减少类的扇出,也即:减少类定义的消息数和发送的消息数的乘积。
(26)如果类包含另一个类的对象,那么包含类应当给被包含的对象发送消息。也即:包含关系总是意味着使用关系。
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。
(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。当类包含多于6个数据成员时,可以把逻辑相关的数据成员划分为一组,然后用一个新的包含类去包含这一组成员。
(29)让系统功能在窄而深的继承体系中垂直分布。
(30)在实现语义约束时,最好根据类定义来实现。这常常会导致类泛滥成灾,在这种情况下,约束应当在类的行为中实现,通常是在构造函数中实现,但不是必须如此。
(31)在类的构造函数中实现语义约束时,把约束测试放在构造函数领域所允许的尽量深的包含层次中。
(32)约束所依赖的语义信息如果经常改变,那么最好放在一个集中式的第3方对象中。
(33)约束所依赖的语义信息如果很少改变,那么最好分布在约束所涉及的各个类中。
(34)类必须知道它包含什么,但是不能知道谁包含它。
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。
(36)继承只应被用来为特化层次结构建模。
(37)派生类必须知道基类,基类不应该知道关于它们的派生类的任何信息。
(38)基类中的所有数据都应当是私有的,不要使用保护数据。类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
(39)在理论上,继承层次体系应当深一点,越深越好。
(40)在实践中,继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。 (41)所有的抽象类都应当是基类。
(42)所有的基类都应当是抽象类。
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。
(44)如果两个或更多个类共享公共数据(但没有公共行为),那么应当把公共数据放在一个类中,每个共享这个数据的类都包含这个类。
(45)如果两个或更多个类有共同的数据和行为(就是方法),那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。
(46)如果两个或更多个类共享公共接口(指的是消息,而不是方法),那么只有他们需要被多态地使用时,他们才应当从一个公共基类继承。
(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下,设计者应当使用多态。
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构,每个属性值都被变换成一个派生类。
(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。
(51)如果你觉得需要在运行时刻创建新的类,那么退后一步以认清你要创建的是对象。现在,把这些对象概括成一个类。
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。
(54)在创建继承层次时,试着创建可复用的框架,而不是可复用的组件。
(55)如果你在设计中使用了多重继承,先假设你犯了错误。如果没犯错误,你需要设法证明。
(56)只要在面向对象设计中用到了继承,问自己两个问题:(1)派生类是否是它继承的那个东西的一个特殊类型?(2)基类是不是派生类的一部分?
(57)如果你在一个面向对象设计中发现多重继承关系,确保没有哪个基类实际上是另一个基类的派生类。
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择,请选择包含关系。
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是,在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
(61)不要绕开公共接口去修改对象的状态。 7月9日 XP下安装SQL Server 2000以及“SQL Server不存在或访问被拒绝”的解决SQL2000企业版本适用于WIN 2000系统、2003系统,但在XP上却并不合适。因为SQL 2000在XP上无法安装服务器端,只能安装客户端。但实际上却并不是不能装服务器端,可以去微软站点下载MSDE就可以了,但MSDE在安装好后只能同时运行5个数据库进程,这里是MSDE的安装方法。而在大型数据库项目中,5个连接进程是不购用的。那就按照以下的方式进行数据库SQL的安装: 一.在SQL服务器的安装盘中找到MSDE这个目录,并且点击setup.exe安装它,过程简单直接下一步就OK了。 下面写下“SQL Server 不存在或访问被拒绝”的解决 一、“SQL Server 不存在或访问被拒绝” 一般说来,有以下几种可能性: 要解决这个问题,我们一般要遵循以下的步骤来一步步找出导致错误的原因。 ============= 首先,检查网络物理连接 ============= ping <服务器IP地址/服务器名称> 如果 ping <服务器IP地址> 不成功,说明物理连接有问题,这时候要检查硬件设备,如网卡,HUB,路由器等。 如果ping <服务器IP地址> 成功而,ping <服务器名称> 失败,则说明名字解析有问题,这时候要检查 DNS 服务是否正常。有时候客户端和服务器不在同一个局域网里面,这时候很可能无法直接使用服务器名称来标识该服务器,这时候我们可以使用HOSTS文件来进行名字解析,具体的方法是: ============= 其次,使用 telnet 命令检查SQL Server服务器工作状态 ============= 如果命令执行成功,可以看到屏幕一闪之后光标在左上角不停闪动,这说明SQL Server服务器工作正常,并且正在监听1433端口的TCP/IP连接。 如果命令返回“无法打开连接”的错误信息,则说明服务器端没有启动 SQL Server 服务,也可能服务器端没启用TCP/IP协议,或者服务器端没有在 SQL Server 默认的端口1433上监听。 =============接着,我们要到服务器上检查服务器端的网络配置,检查是否启用了命名管道,是否启用了 TCP/IP 协议等等============= 点击:程序——Microsoft SQL Server——服务器网络使用工具。 打开该工具后,在“常规“中可以看到服务器启用了哪些协议。一般而言,我们启用命名管道以及 TCP/IP 协议。点中TCP/IP协议,选择“属性”,我们可以来检查SQL Server服务默认端口的设置。一般而言,我们使用SQL Server默认的1433端口。如果选中“隐藏服务器”,则意味着客户端无法通过枚举服务器来看到这台服务器,起到了保护的作用,但不影响连接。 ============= 接下来我们要到客户端检查客户端的网络配置 ============= 点击:程序——Microsoft SQL Server——客户端网络使用工具 通过以上几个方面的检查,基本上可以排除第一种错误。
该错误产生的原因是由于SQL Server使用了“仅 Windows”的身份验证方式,因此用户无法使用SQL Server的登录帐户(如sa)进行连接。解决方法如下所示: 1、在服务器端使用企业管理器,并且选择“使用Windows身份验证”连接上 SQL Server; 在以上解决方法中,如果在第 1 步中使用“使用 Windows 身份验证”连接SQL Server失败,那就通过修改注册表来解决此问题: 1、点击“开始”—“运行”,输入regedit,回车进入注册表编辑器; 此时,用户可以成功地使用sa在企业管理器中新建SQL Server注册,但是仍然无法使用Windows身份验证模式来连接SQL Server。这是因为在 SQL Server中有两个缺省的登录帐户:BUILTIN\Administrators、<机器名>\Administrator被删除。要恢复这两个帐户,可以使用以下的方法: 1。打开企业管理器,展开服务器组,然后展开服务器; 说明: 三、提示连接超时 如果遇到第三个错误,一般而言表示客户端已经找到了这台服务器,并且可以进行连接,不过是由于连接的时间大于允许的时间而导致出错。这种情况一般会发生在当用户在Internet上运行企业管理器来注册另外一台同样在Internet上的服务器,并且是慢速连接时,有可能会导致以上的超时错误。有些情况下,由于局域网的网络问题,也会导致这样的错误。 具体步骤为: 查询分析器中的设置: 四、小问题: 2、怎么在程序中更改Named Pipes , Tcp/ip ,其sql语句怎么写? 我曾经遇到过一个问题应该属于第一类,遗憾的是我按照上面说的方法都不能解决这个问题。我使用:telnet <服务器IP地址> 1433 显示不能正确连接。按照说的方法也不能解决这个问题。有网友说出现1433端口不能连接的因为是Sql Server 2000没有打补丁的缘故,但我打过sp4后仍然不能正确连接1433端口。 |
|
|