我应该创建 DLL 以实现模块化吗？
我正在创建一个应用程序，它将解析 MSDN 文章以获取元信息，例如文章标题和同一集合中的其他文章。这个应用程序还有一个 GUI 前端。
我感兴趣的是通过将前端与后端分离并将后端分为两部分来使该程序更加模块化——一个部分处理 HTML 文档的检索和一般解析，另一个部分执行更具体的操作解析与MSDN本身相关。这个想法是，这将允许将自定义 UI 部署到后端，并允许应用程序仅通过插入不同的 DLL 就能够解析其他站点（可能是 Google 搜索结果）。
我的理解是，您通常会创建 DLL 来在不同的应用程序之间共享代码。然而，在这种情况下，我只是为这一特定应用程序寻找模块化。在这种情况下创建 DLL 是否仍然合适？或者我应该考虑不同的选择，例如将所有类放在一个程序集中？
我应该指出，我对编程还比较陌生，所以即使答案是“否”，那么这仍然是我学习的一个很好的练习。如果是这样的话，我想知道是否应该对这个练习进行修改以使其更合适。
I'm working on creating an app that will parse MSDN articles for meta-information such as the article title and other articles that are in the same collection. This app also has a GUI front-end.
I'm interested in making this program more modular by separating the front-end from the back-end and the back-end into two parts -- one that handles the retrieval and general parsing of an HTML-document and one that does more specific parsing related to MSDN itself. The idea being that this will allow custom UIs to be slapped onto the back-end and allow for the app to be able to parse other sites (perhaps Google search results) just by plugging-in a different DLL.
My understanding is that you would normally create DLLs to share code across different applications. However, in this case, I'm only looking for modularity for this one particular application. Is it still appropriate to create DLLs in this case? Or should I be considering a different option, such as just glomming all of the classes together into a single assembly?
I should note that I'm relatively new to programming, so even if the answer is "no", then this will still be a good exercise for me to learn from. If that's the case, I'd like to know if this exercise should be modified in anyway to make it more appropriate.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为在这种情况下使用 DLL 的想法是个好主意。使用 DLL 没有明显的额外成本（最多可能多一点启动成本）。即使您当前只计划在这一个应用程序中使用它们，仍然为未来的更改做好计划也没有什么坏处。如果需要，DLL 很有可能无需修改即可在另一个应用程序中使用。
此外，将其拆分为单独的 DLL 以实现模块化甚至可能有助于设计和开发过程。它使“共享”全球数据变得更加困难（这可能是一件好事）。如果所有内容都在一个整体程序集中，则可能会倾向于从其他地方获取一些数据。如果该数据存在于另一个程序集中，那么这种潜在的不良做法就不太可能发生。它可能会迫使开发人员重新思考如何解决问题。
I think that your idea of using DLLs in this situation is a good idea. There is no appreciable extra cost in using DLLs (possibly a bit more startup cost at the most). And even if you are currently only planning on using them in this one application, it doesn't hurt to still plan for future changes. There is always a good chance that the DLLs can be used with little or no modification in another application if needed.
In addition, splitting it into separate DLLs for modularity might even help with the design and development process. It makes "sharing" global data more difficult (and that is probably a good thing). If everything is in one monolithic assembly, there may be some tendency to just grab some data from some other place. If that data lives in another assembly, then that potentially bad practice is less likely to happen. It may force the developer into rethinking how to solve issues.
DLL 可以帮助维护您的应用程序。如果您将来有更新和/或错误修复，您可以更新特定的 DLL，而不是整个应用程序。这也将有助于减少您的测试表面积。
在开发过程中，删除某些类/DLL 并在开发后交换实际的 DLL 也会更容易一些。
我不会发疯把每个类都放在自己的 DLL 中。从高层次来看，应该有一个明确的类分组，并且应该在一起。
DLLs can help with maintenance of your application. If you have future updates and/or bug fixes, you can update specific DLLs as opposed to the entire application. This will also help reduce your testing surface area.
During development it will also be a bit easier to stub out certain classes/DLLs and swap in the actual DLLs later once developed.
I wouldn't go crazy and put every class in its own DLL. From a high-level there should be a clear grouping of classes that should be together.
制作 DLL 有几个优点：
它也带来了成本：
，但关于模块化的要点是 DLL 仍然是一个半措施。即使我们忽略成本，它也并不比库好多少，甚至只是重用现有的类。主要优势是针对经销商，而不是真正针对软件开发人员，除非您期望第三方贡献者。并且被调用的函数仍然与主程序运行在同一进程中。
如果您想要真正彻底的模块化，您可以使用真正的多层架构，其中前端和后端具有单独的进程以及它们之间的通信层（例如 TCP 套接字）。在项目生命周期的早期完成时，这通常既更通用，也更强大，而且不会变得更复杂。
There is several advantage to make a DLL:
It also comes with a cost:
But the main point regarding modularity is that DLL is still a half measure. Even if we ignore costs, it is not much better than a lib or even just reusing existing classes. The main advantages are for resellers, not really for software developers, except if you expect third party contributors. And the called functions are still running in the same process that the main program.
If you want a real clean cut for modularity you could use a real multi-tiers architecture with separate processes for front-end and back-end and a communication layer between them (say TCP sockets). That is usually both more versatile and more robust, and not much more complex when done early enough in project life.