在 ASP.NET 中使用 COM，还是使用标准 DLL？
我们正在将带有 VB6 COM 对象的经典 ASP 应用程序迁移到 .NET 世界，并且我们对如何以尽可能简单的方式迁移 COM 对象感到困惑。我发现了很多“如何做”的文章，但很少有“为什么”的文章。我们是否最好将 COM 对象重建为查询数据库的标准 DLL（这是一个数据库密集型应用程序），或者我们应该将它们重建为 C# 中的新 COM 对象？每种方法的优点和缺点是什么？我们还应该考虑采取不同的方法吗？我们在 .NET 方面还不是一个非常强大的商店，因此非常欢迎任何和所有建议。
预先感谢，迈克
We are moving a classic ASP application with VB6 COM objects, over to the .NET world, and we are puzzled about how to migrate our COM objects in as straightforward a manner as possible. I have found a lot of 'how-to' articles, but not much in the way of 'why' articles. Are we better off rebuilding the COM objects as standard DLLs which query the database (this is a DB-heavy application), or should we rebuild them as new COM objects in C#? What are the advantages and disadvantages of each approach? Is there yet a different approach we should consider? We are not yet a very strong shop in .NET so any and all suggestions are most welcome.
thanks in advance, Mike
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个很难回答的问题，因为存在很多变数。让我们假设，对于这个线程，您有相当数量的关注点分离和一组具有良好性能的 COM DLL。
假设上述情况并考虑到您的帖子（COM 组件中的大量代码），我通常会查看的路径是首先在 .NET 中重写 UI，然后使用 .NET 包装器来调用 COM 组件。通过引用 COM 组件可以轻松完成此操作。如果包装后遇到性能问题，转向某些本机 DLL 方法可能会有所帮助，但设置代码来调用本机方法是一个更复杂的方向，因此我不会首先采用该方法。
然后你有两个可能的方向。专注于用户故事（可用性）或专注于迁移各个库（COM DLL >> 一次一个程序集）。我更喜欢故事的方向，尽管你最终可能会得到死代码。我不会考虑迁移，而是一次重写一个故事，这样您就可以专注于在 .NET 中正确完成它。迁移最终会产生大量用 .NET 编写的 COM 代码，这很糟糕。
我会考虑至少找一位 .NET 专家，无论是作为员工还是顾问，这样就不会让旧习惯渗透到糟糕的代码中。聘请这位专家主要是为了让您走在正确的道路上，而不是作为另一组编码人员。并不是说这个人不会编码，但要确保你不要过度利用这个人作为一个温暖的身体，因为他在开发过程中的主要工作是防止你搬起石头砸自己的脚。如果您可以尽早让此人加入，请考虑聘请具有一定架构经验的人员来帮助设计 .NET 应用程序。预先进行试验比稍后进行重构的成本更高。
不要尝试迁移程序。他们不工作。您不仅要进行开发平台的转变，还要进行彻底的范式转变。如果您尝试使用任何自动化工具来迁移代码，您最终会得到一个较差的应用程序。
另一件事。如果您使用 VB，请考虑转向 C#。这听起来适得其反，因为有一个学习曲线，但坚持使用 VB 意味着您将尝试在 VB.NET 中编写 VB6。最终结果是一个糟糕的代码库，很难重构。
This is a hard question, as there are a lot of variables. Let's assume, for this thread, that you have a decent amount of separation of concerns and a set of COM DLLs with decent performance.
Assuming the above and taking your post into account (tons of code in the COM components), the path i would normally look at is rewriting the UI in .NET first and use .NET wrappers to call the COM components. This is easily done by referencing the COM component. Moving to some native DLL method might help if you have a performance problem once wrapped, but it is a more complex direction to set up the code to invoke native methods, so I would not head that route first.
You then have two directions to possibly head. Focus on user stories (usability) or focus on migrating individual libraries (COM DLL >> assembly one at a time). I prefer the story direction, althought you will potentially end up with dead code. Rather than think about migrating, I would rewrite one story at a time, so you are focused on doing it right in .NET. Migration ends up with a lot of COM code written in .NET, which is nasty.
I would consider finding at least one .NET expert, whether hired as an employee or a consultant, so you do not let old habits leak in bad code. This expert should be hired primarily to keep you on the right road and not as another set of coding hands. Not saying the person cannot code, but make sure you do not over utilize this person as a warm body, as his primary job, during development, is to keep you from shooting yourself in the foot. If you can get this person in early, consider hiring someone with some architecture experience to help design the application for .NET. It is more expensive to experiment up front than it is to refactor later.
DON'T try migration programs. They DON'T work. You are not only making a development platform shift, you are making a complete paradigm shift. If you try to use any automated tool to migrate code, you will end up with an inferior application.
One other thing. If you are a VB shop, consider moving to C#. It sounds counter productive, as there is a learning curve, but sticking with VB means you will try to write VB6 in VB.NET. The end result is a bad code base that is hard to refactor.
我的经验建议您应该将 COM 对象重新写入 DLL，因为在转换过程中出现问题的风险很低，而且所需的时间比用 C# 重写要短得多。
迁移到 .NET 只能手动完成，但一旦迁移到 COM DLL 中，您就可以逐个部分地完成此操作。
My experience would suggest you should re-write the COM objects into a DLL because the risk is low that something will break during conversion and the time this will take is a LOT shorter than re-writing in C#.
Migrating to .NET can only really be done by hand, but once in a COM DLL you can do this on a part by part basis.