[讨论].net vs com
<p>.net到底能做什么事情呢?看了好久的帮助AutoCAD .NET 开发人员手册,里面所有的都是dll,在CAD里用netload方法加载dll,然后输入命令就开始执行C#或VB.NET命令后面的那个函数,不知道着样做的效果是什么,有什么用处?不能做应用程序开发。</p><p>用C#或VB.NET引用COM函数库就是CAD Library 和 ObjecDBX之后可以启动CAD,关闭CAD,在里面做各种操作,绘图,发送命令等,还可以用AxdbDocument接口,个人觉得功能要强于.NET开发用引用的<em>AcDbMgd.dll.</em><em>AcMgd.dll.</em> 。</p><p>不知道大家的看法怎么样?</p> <p>比较一下吧</p><p>1、AutoDesk的关注程度</p><p>Com库是早已放弃的残次品</p><p>NetApi功能不断加强</p><p>2、曲线操作</p><p>Com库是没办法实现的,必须借助vlax,但很不稳定</p><p>NetApi提供了Curve类,可以简单的实现</p><p>3、拖动</p><p>Com同样没有提供,也许会说没必要,但你不会觉得很Cool么:)</p><p>NetApi提供</p><p>4、Cad界面</p><p>Com库是一直支持</p><p>但2009以后的RIBBON界面只能用NetApi做</p><p>5、发送命令</p><p>Com库的支持很差,容易引起程序执行混乱</p><p>NetApi没问题</p><p>6、你上面说的</p><p>Com库也是必须打开Cad的</p><p>NetApi是可以作出命令调用的</p> <p>版主又教了我好多东西啊,谢谢版主!</p><p>还有2个问题,就是关于.NET API的命令调用,在CAD里面加载了.NET 开发的dll之后,可以在命令窗口中输入dll定义的命令来执行相应操作,但是如果需要批量执行同一条命令怎么办呢?比如需要从oracle或者access数据库中读取数据,然后每读取一条数据后,需要调用.NET 开发的dll里的命令,这个时候我怎么实现呢?</p><p>还有.NET 开发的dll能不能永远加载到CAD程序里面呢,就是关闭CAD之后,下次打开的时候还可以使用dll的命令,不需要每次都去人工加载?</p> <p>1、为什么有这种需求?</p><p>单独的命令也可以完成的</p><p>2、Net开发的dll可以在AutoCad启动时加载,如同ObjectArx一样</p><p>看看这里三楼</p><p><a href="http://bbs.mjtd.com/forum.php?mod=viewthread&tid=75796">http://bbs.mjtd.com/forum.php?mod=viewthread&tid=75796</a></p> <p>这里有Autodesk二次开发专家在官网的文章,关于Com和Net的</p><p>This was a topic suggested by Scott Underwood (thanks, Scott! :-) to look at COM vs. NET and go through their respective advantages and disadvantages…</p><p>This is really an interesting discussion topic, and one that I’d like people to help turn into an interesting discussion. I can certainly talk about the differences and pros/cons of the two technologies from my own memory/experience/perspective, but others will have things to say on this, I’m sure... please feel free to do so! :-)</p><p>Rather than going into low-level detail on either COM or .NET, I’d suggest looking into their respective Wikipedia sites. Both do a fair job of listing the criticisms made about the respective technologies, but not all will apply here (the .NET Framework is part of the AutoCAD install, so availability/deployment is not such a big issue for us, for instance).</p><p>So let's start with some generally AutoCAD API background…</p><p>Both COM and .NET APIs (and actually also AutoLISP, since it's re-implementation as Visual LISP back in R14.01) are implemented via ObjectARX – they are basically ARX modules loaded into AutoCAD that expose COM and managed interfaces respectively. That said, as more core AutoCAD development happens using .NET, it’s no longer necessarily true that managed interfaces will always be exposed through (and available in) ObjectARX. The decision about which technology to use to expose an API is driven by its market requirements.</p><p>Now a little more specific history on each of the technologies…</p><p>COM Automation (originally OLE Automation, changed to ActiveX Automation, and now it’s either COM Automation or just Automation)</p><p>AutoCAD’s COM Automation API was first introduced with VBA back in R14.01. At the time it was pretty revolutionary, as it was an API that was implemented via a technology that genuinely allowed developers to choose their own development technology (as long as it was Visual Basic… just kidding ;-). It was also the technology that enabled some very clever features in AutoCAD: the Properties Palette uses COM Automation to query and edit properties of objects, for instance. QSELECT is another one.</p><p>One of the big problems with COM is the effort needed to expose COM interfaces: the COM Automation standard supports a relatively small set of data-types (unless you make nearly everything its own object, and that just gets unmanageable), which means that complex C++ interfaces need to be fundamentally re-designed (often flattened) to be exposed through COM.</p><p>.NET</p><p>When AutoCAD was first built using Visual Studio .NET (during the AutoCAD 2004 timeframe), the door was opened to expose a managed API. While this was prototyped on AutoCAD 2004, it first made it into the shipping product as part of AutoCAD 2005. Exposing a managed interface is much easier than a COM Automation interface... in fact the AutoCAD team has managed to semi-automate the process of exposing its managed interfaces. This definitely helps us keep the managed API in synch with ObjectARX, where - as mentioned earlier - much of it is exposed from.</p><p>Incidentally, a managed API to AutoCAD also enables Autodesk to do more internal development using .NET, rather than all of it being in unmanaged C++ (much of its feature development work is still done in C++/ObjectARX, but that's changing). It enables us to take advantage of many of the advantages of the .NET Framework, such as the tools around creating user interfaces, accessing data, etc.</p><p>And now let’s compare some of the specific differences, stepping through some typical API comparison criteria, one-by-one... (I would have liked to make a little matrix showing this, but felt the need to flesh out the explanations.)</p><p>Performance</p><p>Both technologies are comparable in terms of speed of execution – neither introduce much execution overhead when compared with ObjectARX (unless you’re using COM out-of-process – more on that later).</p><p>Future-proofness (if that’s even a word :-)</p><p>COM is being extended as per the needs of various AutoCAD features (Properties Palette support, etc.), but you will see more rapid expansion of .NET capabilities. Additionally Microsoft is 100% behind .NET, and I genuinely believe it has a much brighter future.</p><p>Simplicity</p><p>This is subjective, but overall I would say the COM object model is simpler to learn. That doesn’t mean I prefer it, though. (How’s that for subjective? :-)</p><p>Power</p><p>.NET is more extensive in terms of its level of API exposure and also has more powerful platform capabilities (although that's more when you get into comparing VB6 with VB.NET).</p><p>Interoperability</p><p>COM environments such as VBA/VB6 can use all sorts of COM components and even DLL/EXE exports, but from .NET you can use much, much more (COM, .NET, native C++ etc.)</p><p>Support in shipping AutoCAD versions</p><p>COM is available throughout our shipping versions of AutoCAD while .NET is not quite there yet. Although it won't be long before all supported versions of AutoCAD have a managed API, our .NET implementation evolved substantially between 2005 and 2006, and AutoCAD 2005 will still be supported for some time. If you need to support multiple versions, this is something you need to be aware of.</p><p>IPC (Inter-Process Communication)</p><p>COM’s big advantage – and frankly the main reason I use it at all – is that it was designed to be used across processes. While .NET Remoting is possible with some applications, AutoCAD’s managed interface was not designed to work across the process boundary (just as ObjectARX was not).</p><p>Conclusion</p><p>If I had to learn a new API for AutoCAD at this stage (and didn't know any of them), I would choose .NET. It may be more complex to learn, but it is more extensive, it has better long-term potential both as an API and a programming environment (in terms of support from Microsoft and Autodesk), and frankly you can make very easily make use of AutoCAD's COM Automation interface from a .NET environment. It has very good coverage of the overall ObjectARX feature-set, and much of what isn't exposed can be accessed using P/Invoke. If you need to drive AutoCAD from an external executable, then I’d suggest using COM to drive AutoCAD out-of-process, loading a .NET component in-process to do the heavy lifting.</p><p>The main caveat about all this is around platform support. Until your customer(s) all use a version of AutoCAD that exposes the API set you need, you might well need to invest time developing with other technologies. This was also an issue when ADS, ObjectARX and COM/VB(A) were introduced (and probably even AutoLISP, although I don't go back quite that far).</p> <p>比如在石油化工设计的时候,有很多类似的图纸,只是有些参数不一样,经常会有几千张图纸,而每一张图纸的那些不一样的参数都存放在Excel里面(这是按行业设计标准规定的,必须存放在excel,或者数据库里面,不得更改,否则拿不到设计费),每张图对应Excel的一行数据,总共有几千行,那么这个时候怎么使用这个.NET开发的dll呢?</p><p>我想可以这样,用vs2008/2005引用cad com和Excel com编写应用程序,让应用程序连上cad,然后循环从excel取数据,每取一行,向cad发送命令(就是用.net开发的dll的命令),并带参数来完成绘图,之后再保存关闭这个drawing.但是版主说cad com发送命令容易出现错误。所以现在就不知道用什么办法来完成这种需求了。</p> <p>石油化工设计,和我以前的专业类似:)</p><p>如同我上面所说,单独的命令就可以把几千条数据处理掉</p><p>而且都用Arx了,为什么还去调用命令呢,Cad命令可以实现的功能,NetApi基本上都可以解决</p><p></p> <p>我是说调用.net开发的命令,不是调用cad自己的命令</p><p>一条命令就解决几千行数据好像不太可能吧,毕竟数据是存放在excel或者数据库里面的。需要com调用excel或者oracle或者access来取数据的。</p> <p>调用.net开发的命令?是函数?</p><p>没有问题的</p><p>NetApi一样可以用Com调用Excel</p><p>你也可以把Excel直接作为数据库连接</p><p>几千行数据可以说清楚些么?</p>
页:
[1]