项目和DLL:如何使其可管理? [英] Projects and DLL's: How to keep them managable?

问题描述

我想知道分离dll的最佳和最可维护的方法是什么?
我正在构建一个WinForms应用程序，该应用程序使用要在其他应用程序中重用的类.所以这是要抓住的地方:

假设我构建了一个名为StringManipulator的库，将其放在单独的项目文件中，并将其构建为dll.很明显它是做什么的.现在，我需要一个调用我的StringManipulator.dll的用户界面.对于此用户控件，我正在制作一个名为StringManipulator.WinForms.dll的新项目.我这样做是因为稍后可能需要在WPF应用程序中使用StringManipulator.

所以有点像这样:
StringManipulator.WinForms.dll需要StringManipulator.dll

所以我现在有两个dll，还不错.但是随着应用程序的进展，我有了许多dll，它们都由一个通用部分和一个WinForms特定部分组成.许多dll只有一个或两个类，并且都很难维护(新代码应该在现有dll中还是在另一个新dll中去?).再加上一个应用程序实际上可以引用所有二十个dll，这对我来说似乎很多...

现在的情况看起来更像是:
Project1.WinForms.dll需要Project1.dll
Project2.WinForms.dll需要Project2.dll
...
Project10.WinForms.dll需要Project10.dll

那已经使十个用途的二十个dll ！！
为了使事情变得容易，我将所有WinForm控件都放在一个dll中.错误的！我的WinForm dll现在引用了大约10个其他dll.现在，当一个应用程序需要一个WinForm组件时，即使我只需要一个控件，我也需要部署所有dll.

看起来像这样:
WinFormsProject.dll需要Project1.dll，Project2.dll ... Project 10.dll

现在，我当然不是唯一遇到此问题的人.我已经阅读了有关DLL颗粒化的信息( Robert Martin的这些文章也不少！ [ 现在，我非常支持拥有许多dll，即使它们每个只有一个或两个类.当然，我们仍然必须部署许多dll，但是至少它们将全部被使用.另一种选择是将所有内容都放入一个大项目文件中，因为我们现在无论如何都必须部署所有内容.

在目前的开发阶段，我可以相对容易地将WinForms组件分解为许多小组件.将来，我们将在更多应用程序中实现dll，并且进一步隔离将变得更加困难.

我想听听这里人们的意见和经验.您有什么建议和推荐?如果我们选择一种或另一种方式有什么建议吗?

谢谢.

I was wondering what is the best and most maintainable way to seperate your dll''s?
I am building a WinForms application that makes use of Classes I want to re-use in other applications. So here''s the catch:

Let''s say I build a library called StringManipulator, put it in a seperate project file and build it as a dll. Pretty obvious what it does. Now I want a user interface that calls my StringManipulator.dll. For this user control I am making a new project, called StringManipulator.WinForms.dll. I do this because at a later time I might need the StringManipulator in a WPF application.

So it''s a little like this:
StringManipulator.WinForms.dll needs StringManipulator.dll

So I now have two dll''s, not so bad. But as the application progresses I have MANY dll''s, all consisting of a general part and a WinForms specific part. Many dll''s have only one or two classes and it all becomes quite hard to maintain (should new code go in an existing dll or in yet another new dll?). Plus a single application could actually reference all twenty dll''s, which seems like a lot to me...

Things now look more like:
Project1.WinForms.dll needs Project1.dll
Project2.WinForms.dll needs Project2.dll
...
Project10.WinForms.dll needs Project10.dll

That already makes twenty dll''s for ten uses!
So to make things easier I put all WinForm controls in a single dll. Wrong! My WinForm dll now references about 10 other dll''s. Now when an application needs one WinForm component I need to deploy ALL my dll''s even if I needed just one control.

It looks like this:
WinFormsProject.dll needs Project1.dll, Project2.dll ... Project 10.dll

Now surely I am not the only one with this problem. I''ve read about dll granulation (these articles by Robert Martin no less![^]), but I''ve also seen posts on the internet where companies had 50 dll''s and where building, maintaing and deployment became a nightmare.

Currently I am in a situation where one dll references many which in turn reference other dll''s too. Now a colleague wanted to use a single control from the WinForms dll and as a result had to deploy ALL dll''s (about twenty) that he doesn''t use at all (now actually this just means copying a folder full of dll''s to the customer).
Now I am pretty much in favour of having many dll''s even if they have only one or two Classes each. Of course we''d still have to deploy lots of dll''s, but at least they would all be used. Another alternative would be to just throw it all in one big project file since we now have to deploy everything anyway.

At the current stage of development I could relatively easy break up the WinForms component into many small components. In the future we will be implementing our dll''s into more applications and segregating further will become more difficult.

I''d like to hear the opinions and experiences of the people here. What do you suggest and recommend? Any tips if we choose one way or another?

Thanks.

推荐答案

这就是为什么为每个帮助程序类创建dll是一个愚蠢的主意.我主要将事情分解开来，以分隔项目可能不使用的东西，或者限制我的主要exe文件的大小，例如，我有一个DLL，其中包含很多我们使用的很大的UI图像，所以我不这样做.如果我曾经发送过补丁，则本质上不需要运送这些补丁.从表示层突破您的业务流程是很明智的.编写500个dll并不那么聪明.

This is why making a dll for every helper class is a dumb idea. I would break things apart mostly to seperate things that a project may not use, or to limit the size of my main exe, such as, I have a dll with a lot of the UI images we use that are large, so I don''t need to ship those in essence if I ever send a patch. Breaking out your business process from the presentation layer is smart. Writing 500 dlls is not so smart.

首先要考虑的是依赖层.然后，您应该设计每个层为上述层提供平台的方式.是否应与您的构建过程同步；一层中的所有代码都应依赖于其下的多个层之一，而不要依赖于其上的任何层.

您应该首先对分层体系结构进行图片和文档记录，然后是DLL.

在DLL中拆分代码与之没有直接关系，但是可以肯定的是，没有DLL应该是跨级别的.整个层在一个DLL中实现并不是很不典型.但是，不止一个DLL实现了同一层.在这种情况下，每个DLL代表同一层上的隔离责任域.在这种情况下，应该再添加一个依赖项约束:同一层上的DLL不应相互依赖.



跟进有关维护，适当的开发周期和测试的讨论:

我通常引用 Joel Spolsky 的两篇著名文章，也许每个开发人员都应该知道:

乔尔测试:改进代码的12个步骤， http://www.joelonsoftware.com/articles /fog0000000043.html [ ^ ].

您没有测试人员的前五(错误)原因， http://www.joelonsoftware .com/articles/fog0000000067.html [ ^ ].

请阅读它们，自己得出结论.

—SA

First thing you have to think about is dependency layers. You should design then the way each layer serves a platform for the above layers. If should be in sync with your build process; all code in a layer should depend on one of more layers below it, never on anything above.

You should picture and document your layered architecture first, and the DLLs come next.

Breaking the code apart in DLL is not directly related to is, but certainly, no DLL should be a cross-level one. It is not very untypical that the whole layers is implemented in one DLL. However, more then one DLL implements the same layer. In this case, each DLL represents an isolated field of responsibility on the same layer. In this case, one more dependency constraint should be added: the DLLs on the same layer should not depend on each other.



Following up the discussion related to maintenance, proper development cycle and testing:

I usually quote two famous article by Joel Spolsky which maybe every developer should know:

The Joel Test: 12 Steps to Better Code, http://www.joelonsoftware.com/articles/fog0000000043.html[^].

Top Five (Wrong) Reasons You Don''t Have Testers, http://www.joelonsoftware.com/articles/fog0000000067.html[^].

Please read them, draw your conclusions by yourself.

—SA

这是一个单独的主题:但是请考虑添加一些插件体系结构.
请在我们对本页面上先前答案的讨论中的评论中看到一些动力.

简介:插件不应创建任何依赖项.更确切地说，任何组装都不应依赖于插件.也就是说，除了测试和演示之外，它们都处于分层模型的最高层.即使主机应用程序依赖于插件，也不是循环依赖:插件可以取决于主机应用程序，甚至可以引用主机应用程序的程序集(在.NET中，EXE文件可以与任何其他程序集一样被完全引用) ，但主机应用程序仅在运行时依赖于插件.

我已经在这里详细解释了此应用程序的框架:
在现有实例上的C#反射InvokeMember [创建使用可重载插件的WPF应用程序... [^ ]，
AppDomain拒绝加载程序集 [使用CodeDom生成代码 [动态加载用户控件 [ http://www.west-wind.com//presentations /dynamicCode/DynamicCode.htm [ ^ ].

如果您只需要插件"，则可以忽略重新加载问题.

—SA

This is a separate topic: but please consider adding some plug-in architecture.
Please see some motivation in my comments in our discussion over my previous answer on this page.

Introductory notes: plug-ins should not create any dependencies. More exactly, no assembly should depend on plug-ins. That said, they go on the very top level of layered model, except perhaps tests and demos. Even though host applications depend on plug-ins, this is not a circular dependency: plug-ins can depend on host application and can even reference the assembly of host application (in .NET, EXE files can be referenced exactly as any other assemblies), but the host application depends on plug-in during run-time only.

I have explain the skeleton of this application in detail here:
C# Reflection InvokeMember on existing instance[^].

Please see my other past solutions:
Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^],
code generating using CodeDom[^],
Dynamically Load User Controls[^].

I must apologize that in first post above and some other posts I discuss some aspect which is much more advanced than what you might need: working across the boundary between different Application Domains. You only need that if you need not just to load them, but also re-load during run time. The problem is that it is not possible to unload any loaded assembly, but you can only unload it with the whole Application Domain.

On this topic, see also this article: http://www.west-wind.com//presentations/dynamicCode/DynamicCode.htm[^].

If you need "just plug-ins", you can ignore re-loading problem.

—SA

这篇关于项目和DLL:如何使其可管理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！