辅助绘图工具的方案选择过程是复杂的，从去年8月底就开始了初步的调用，也经过了种种碰壁，最终得出了基本的方案。
先说一些题外话：为什么需要辅助绘图设计？加班的庞大工作量来自于哪里？
单位目前主营业务是地铁信号系统工程总承包，包括地铁新建及改造项目工程管理、系统设计、产品研发、系统集成、测试验证等一整套解决方案和服务。未来的集成方案规划为中心、地面、车载。不管哪个子系统都不可避免的需要设计绘图工作，由绘图生成各个子系统的元数据，根据这些元数据进行代码的数据配置工作。不同的城市不同的线路分别进行不同的设计绘图、数据生成、数据配置等等工作，由此可想象到里面的工作量。然而这种加班并没有创造新的价值也没有带来新的利润，实际上都是一种无偿奉献。所以不是表面上的加班多，就代表项目多，创造了很多新的利润。
企业在未来要想更好的生存，就必须赢得更多的利润，更少的加班成本。这样一个良好的辅助绘图工具设计，一个优秀的数据配置设计的需求就非常的强烈。少加班或者不加班的唯一有效办法就是开发更好用的设计、绘图软件，需求一变操作软件马上可以把成果弄出来。
话说辅助绘图辅助数据配置工具如何设计呢？
辅助绘图的关键在于：设计数据-图元映射关系，因此所作的方案调研之中该方向就是核心诉求。最终的方案趋向于基于objectArx的二次开发。
基于objectArx的二次开发，该类库为C#专用类库。ObjectARX直接访问AutoCAD的数据库结构、图形系统以及AutoCAD几何构造核心，因此在运行期间能实时拓展CAD功能，也能复用CAD固有的命令来开发新命令。CaD数据库的核心是BlockTable，BlockTable和所有Block具有一一映射关系。BlockTable此表含有两个非常重要的记录：模型空间和图纸空间，所有的实体(可见对象)均放于块表AcDbBlockTable中。
其它的设计方案并不具有如此完备的数据-图元映射关系，所以在图元生成数据和数据反向生成图元方面先天不具备优势。
Autolisp和VBA是初期的二次开发方案，因为不具备完备的面向对象特性而逐渐淘汰。
基于SDK类库的C++语言开发并未进入主流方案，其主要原因可能是因为二者的兼容性问题，虽然C++在面向对象方面较为强大，但是和ObjecArx在操控各种blocktable方面开发效率不高，所以时至今日也未能进入主流。
其它的绘图工具，仅仅就是绘图工具，反向生成图元不能说不可行而是得不偿失地需要进行大量的图元设计和数据设计工作。
ObjectArx能够直接访问CAD的图形数据库BLockTable的特性，使得通过ObjectARX类库二次开发能够获得BlockTable与Block的强映射关系，这种强映射关系正好满足了辅助绘图工具的需求。
一副CAD图形就是一个包含有多个表的数据库，它规定了9个符号表，具体如下：
而网上对ObjectARX的学习资料少之又少，学起来是一个相当困难的挑战，但是真的就没有解决方案了吗？通过大量的调研始终找不到学习资料。
就算费劲苦心参考资料甚至视频教程，又能坚持在没人指导、没人咨询、没有案例的情况自己沉浸进去吗？
于是把眼光投向了培训机构，经过达内、青鸟、网易课堂、腾讯课堂重重筛选找到了腾讯课堂的云幽学院。该学院是目前为止教授较为完备的CAD深度开发的地方，里面有一个技术团队专门做技术指导，有大量的视频笔记案例供参考学习。我想花一些小钱进行学习也是有必要的。
另外一个方案就是设计院的请外包方进行二次开发工作，此时外包的费用问题又是一个需要考虑地方。