踩坑（Running）填坑（ZSSURE）：DevExpress的XtraTabControl、Telerik的OpenAccessContext以及StarUML

题记：

今天好友在朋友圈分享了一篇有深度的好文“请鼓励你的孩子做个幸福普通人”，文章略显长，细细品读下来感触颇多。加之最近天天看着小外甥大睿睿的一步步的成长，已渐渐远离年轻稚嫩、走向成熟稳重的我对学习有了新的认识，回想起自己的成长过程，经验和技能并非是父母手把手教导的，反而是他们给我营造的“自由、开放、甚至略显放纵”的环境、他们以身作则的行动，让我从中体会、感悟出了所有的点点滴滴。
说到现在从事的软件研发工作，想想同学中毕业鲜有留下来做技术的（姑且认为IT民工也属于技术一波吧），无非是因为这份工作辛苦、有压力、报酬少。为什么自己却选择了留下来？原因很简单，想通过这样一个高强度、高自由度、高变化度的环境时刻提醒自己“不忘学习新知识、积累新技能”。生活的技能、应试的技能、谋生的技能，技能本身无优劣之分，视应用场景不同而定。IT和互联网教会我们的是自由、开放、锐意进取，要时刻充实自己才能不被淘汰，这条真理放之四海而皆准，各行各业都如是。
对于引文中的观点，深感赞同之际，也有自己的看法:

【zssure】：婴儿的出生，从器官有了感觉开始，一缕微风、一丝清香、一点声响、一次抚摸，一切的一切都已被吸收，并逐渐从中提取信息为后续的积累做储备，正如同现在火热的AR技术一样，人类拥有最强的大脑来处理无数海量的数据，随着时间的增长、采集信息的增加，经验和技能也就随之而形成。因此成长是需要时间去感悟的、技能同样如此。

家长一时的强迫或许会奏效，但终究不会积累下来形成技能。生活和工作中，我们会遇到种种问题，或许利用强大的谷歌或百度我们可以在瞬间找到解决方案，但为什么我们少有成长，技能鲜有提升呢？究其原因就是没有形成积累，自然也就不会转化为技能。
综上所述，也正是我决定并坚持写博文的用意，或许博客已经不是主流交流平台、或许最终博客会被其他新生事物所代替，但这不是我要考虑的，我所要做的就是找一块“净土”，收集日常生活的点滴，随着时间的流逝，将其转化成技能以应对生活和工作中的挑战，仅此而已。

谨记:博文中希望对工作或生活中遇到的问题进行记录、剖析、解决 ，并写出自己的感悟。在供自己回味品读的同时，也希望与志同道合者进行交流互动。倘若工作或生活中你也遇到了同样的问题，如果非紧迫必要，希望可以细细品读、并在解决问题后写出自己的感悟，如是才能达到提升的效果；如果博文中的方案不适合你的场景，有兴趣也可邮件我相关信息，我们一同分析探讨，最后写下彼此的感悟，共同成长，共同进步，以此共勉！

背景：

踩坑填坑系列博文坚持之前的约定，主要用于记录工作中遇到的各种问题，或简单，或繁琐。在还未详细剖析之前，先找到解决方案解决工作上的燃眉之急，待有时间后会整理成文，PUSH到日积月累系列中。此次“踩坑填坑”系列博文中介绍的内容略显分散，各问题之间毫无关联性（当然从我实际的项目本身来说还是有关联性的），从DevExpress WinForm控件，到Telerik OpenAccess ORM，再到StarUML建模，问题都是比较容易踩的、隐蔽的坑，详情如下文。

踩坑填坑:

1）XtraTabControl的BackColor修改

在使用DevExpress的XtraTabControl控件时，发现其内部的XtraTabPage的BackColor无法修改，无论如何都是Transparent，如下图所示：


此时可以看到XtraTabControl的TabPage内页都是白色透明的，使用起来很不美观。在谷歌或百度检索相关问题，大致会弹出如下结果:

试用一下会发现，都无法达到修改XtraTabPage的BackColor的效果。最终还是在万能的StackOverflow找到了解决方案，很简单。
【解决方案】:

按照上图方案，修改前后的对比图如下,明显感觉舒服了许多。

2）Telerik OpenAccessContext的使用

之前博文介绍过如何使用Telerik OpenAccess操作SQLite数据库，今天在实际应用过程中又遇到了一个小问题，后来经过仔细排查发现是自己项目架构的问题所致。问题简单描述如下:
1)项目整体框架：项目中总共包含三个工程，分别是ProjectA、ProjectB、ProjectC，其中ProjectA就是使用TelerikOpenAccess完成的数据库操作类库，ProjectB和ProjectC同时引用ProjectA。项目具体应用场景是，在ProjectB中进行相关数据库的添加、修改和删除操作；在ProjectC中进行数据库的查询和UI显示操作。
2）实际遇到的问题 ：ProjectB和ProjectC作为独立应用WinFrom.exe进行部署，在实际调试过程中，ProjectB可以顺利完成数据库的添加、修改和删除操作，但是ProjectC中的查询结果一直返回为“空”。单步调试到Telerik OpenAccess的代码内也并未发现任何异常。
【解决方案】:最后仔细对比发现，在ProjectB.exe和ProjectC.exe目录下都存在一个XXX.db数据库文件，其中在ProjectB目录下的数据库文件内存有数据，而ProjectC目录下的数据库文件为空。究其原因是ProjectB和ProjectC在应用ProjectA进行数据库操作时，调用OpenAccessContext类的构造函数：

    public OpenAccessContext(string connectionString, BackendConfiguration backendConfiguration, MetadataContainer metadataContainer);

进行数据库构造时使用的连接字符串未使用绝对路径，因此导致ProjectB和ProjectC两次调用OpenAccessContext构造的数据库分别在对应工程可执行文件目录下创建了数据库文件，因此导致数据库添加、删除和修改，与查询使用的不是同一个数据库文件。因此在ProjectC项目中调用ProjectA的OpenAccessContext构造函数时，对数据库的连接字符串给出绝对路径，例如
C:\TelerikOpenAccess\Sqlitetest\ProjectB\Debug\X86\xxx.db。如是即可顺利实现预定功能。

3）StarUML的Diagram与Model的区别

UML对于软件开发人员来说是必备技能，前期需求设计时用于构造结构图、时序图、用例图；后期开发时需要用于构建类图；最终部署时还需要进行部署设计。每一个环节都可以使用UML进行描述，最近抛弃了传统的MS的Viso工具，转而开始使用StartUML，瞬间被友好的界面，丰富的图类，简洁的操作所征服，但是在初次使用时还是被StarUML的Diagram和Model概念搞得一头雾水，下面就来简单区分一下这两个概念:

• Model或（Software
  Model）是对系统各方面的描述，例如结构（structure）、行为（behavior）、需求（requirement）等等。
  

• Diagram是Model（Software
  Model）的一种可视化的几何符号表示。一个Model可以用多个Diagram来表示，每一个Diagram代表一个方面，例如Diagram1用于表示类之间的继承关系（类图），Diagram2用于表示具体对象之间的交互（时序图）。

在StarUML的Explorer窗口中可以看到各种元素之间的关系，通过尝试大致可以这样理解。
Add Diagram用于添加可视化的图形，诸如我们常见的类之间的继承图、时序图等等；而Add用于添加具体的模型，该模型对应到我们工程中实际的Class类，但是在StarUML中无法可视化显示。
举一个例子，例如Class Diagram，在ClassDiagram中用图形符号以可视化的形式表示出各个类，例如类之间的继承关系、类的成员、类的接口、类的属性等等，而Class是具体事物的抽象，是理论建模，表明各部分之间的关系。下图给出一个具体的ClassDiagram，

图中每一个矩形（可视化符号）都代表一个Class类，对应我们C++/C#/JAVA语言中常见的代码，诸如下面示例代码

abstract class Book{public string ISBN;public string title;public int summary();public void publisher(string title);……}

上面在StarUML的Explorer窗口中的具体显示如下：

由此可以看出，在ClassDiagram对象中我们放置了矩形可视化符号用来表示Book这一抽象类，而与之对应的Book类定义模型在Explorer窗口中ClassDiagram下方给出，并罗列出其各种属性和操作。由此可知ClassDiagram中直观、可视化展示的就是其下方中定义个各种类。
PS: 另外操作StarUML时要注意区别Delete和Delete from Model两个操作。通过上面的分析我们大致可以知道两种操作的具体作用，Delete操作使用‘del’键完成，用于删除ClassDiagram等Diagram中的可视化的符号，也就是上图中的矩形，但该操作并不会删除StarUML的Explorer中的Book类模型；而Delete from Model操作在删除Diagram中的可视化符号的同时也会删除StarUML的Explorer窗口中的类的模型。具体使用时要注意。






作者：[e-mail]
时间：2015-04-29