问题
...if there is such a thing. Here's an image of two approachs for structuring DLLs/references in a .NET application: http://www.experts-exchange.com/images/t80668/compArch.png. The app can be a website (it is in this case) or a winform. Each box represents a DLL. For the winform app, just replace "webcontrols" with "winformcomponents".
The first (top) image is what I like. You might want to extend "some" of the base web controls and directly use others. The 2nd image makes you extend any web controls via interface. To me that seems overkill since you may want to simply use what is already there without modification. Which is better and what are the advantages/disadvantages?
The first image puts the lowest common constructs(exceptions, fileIO, constants, etc) into a common.dll. The 2nd image puts app business logic and common into one DLL. Which is better and what are the advantages/disadvantages of each apporach?
回答1:
Having lots of references is usually bad because loading DLL's has a non-negligble cost. It's not as elegant perhaps, but having fewer modules improves your performance. As so often in our craft, you have to find the balance between elegance of total modularization and the harsh reality of performance. And as usual in our craft, you won't know what balance is until you start profiling to measure the performance of your application.
回答2:
I think this is a really down to programmer preference.
It all boils down to dependencies really. More things in one DLL means it will naturally create many more depentdents on that DLL.
I personally tend to follow along similar lines to the MS structure, for these reasons:
- It makes it easier for newcomers to the custom "framework" to find what they want (e.g.
CompName.Web.UI
andCompName.Data
. - It helps reduce the dependencies to "obvious" choices. I am not too keen on
CompName.Common
type DLL's because it does not clearly indicate possible dependents, whereasCompName.Web.UI
suggests that it is likely to be used by any web apps. - Obvious size reduction, since DLL content will be more "relevant".
DLL's for tiers within an app make sense, the types within should only be those types required by the business model, other objects (such as utility, data access etc.) should be in their own libraries.
来源:https://stackoverflow.com/questions/312789/proper-net-dll-structure-for-app