我正在创建一个应用程序来解析MSDN文章中的元信息,例如文章标题和同一集合中的其他文章。这个应用程序还有一个GUI前端。
我有兴趣通过将前端与后端和后端分成两部分来使这个程序更加模块化 - 一个处理HTML文档的检索和一般解析,一个进行与MSDN本身相关的更具体的解析。这个想法是,这将允许自定义UI被打到后端,并允许应用程序只需插入不同的DLL即可解析其他网站(可能是谷歌搜索结果)。
我的理解是,您通常会创建DLL以跨不同的应用程序共享代码。但是,在这种情况下,我只是在寻找这个特定应用程序的模块化。在这种情况下创建DLL仍然合适吗?或者我应该考虑一个不同的选项,例如将所有类组合成一个组合?
我应该注意到我对编程比较陌生,所以即使答案是“不”,那么这对我来说仍然是一个很好的练习。如果是这种情况,我想知道是否应该修改此练习以使其更合适。
答案 0 :(得分:7)
我认为你在这种情况下使用DLL的想法是个好主意。使用DLL没有明显的额外成本(最多可能需要更多的启动成本)。即使您目前只计划在这个应用程序中使用它们,仍然计划未来的更改也没有什么坏处。如果需要,DLL很可能在很少或不需要修改的情况下使用。
此外,将其拆分为单独的DLL以实现模块化甚至可能有助于设计和开发过程。它使“共享”全球数据变得更加困难(这可能是一件好事)。如果所有内容都在一个整体组件中,那么可能有一些趋势只是从其他地方获取一些数据。如果该数据存在于另一个程序集中,那么这种可能不好的做法就不太可能发生。它可能会迫使开发人员重新思考如何解决问题。
答案 1 :(得分:1)
DLL可以帮助维护您的应用程序。如果您有将来的更新和/或错误修复,您可以更新特定的DLL而不是整个应用程序。这也有助于减少测试表面积。
在开发过程中,将某些类/ DLL存根并在以后开发时交换实际的DLL也会更容易一些。
我不会发疯并把每个类放在自己的DLL中。从高层开始,应该有一个明确的类别组合在一起。
答案 2 :(得分:1)
制作DLL有几个好处:
它还带有成本:
但关于模块化的要点是DLL仍然是一半。即使我们忽略了成本,它也不比lib更好,甚至只是重用现有的类。主要优势是经销商,而不是软件开发人员,除非您期望第三方贡献者。被调用的函数仍然在与主程序相同的进程中运行。
如果你想要一个真正的模块化整体切割,你可以使用真正的多层体系结构,前端和后端有独立的进程,它们之间有一个通信层(比如TCP套接字)。这通常既更通用又更强大,而且在项目生命中尽早完成时并不复杂得多。