Menu
The question involves some other related questions, I'll just throw every single on of them feel free to answer one or many of them.
I'm asking this question because I've got this big solution with so many different classes and because now I need to separate some interfaces it's all falling apart (circular dependency problem) and now I need to create multiple DLLs, I just want to be sure to do it in the right way this time.
752
Some companies have a policy to put commonly used assemblies (DLL's) into source control. If you own the source code, this should never be done. These assemblies should be built during the build process.
A dynamic link library (DLL) is a collection of small programs that larger programs can load when needed to complete specific tasks. The small program, called a DLL file, contains instructions that help the larger program handle what may not be a core function of the original program.
In Microsoft Visual C++ 6.0, you can create a DLL by selecting either the Win32 Dynamic-Link Library project type or the MFC AppWizard (dll) project type. The following code is an example of a DLL that was created in Visual C++ by using the Win32 Dynamic-Link Library project type.
An assembly is a collection of types and resources that are built to work together and form a logical unit of functionality. Assemblies take the form of executable (.exe) or dynamic link library (. dll) files, and are the building blocks of . NET applications.
The answer to this question could be very long regarding the scope of the argument, I think first of all it could be better to focus what are the choiches and the reasons that made necessary to separate items in multiple assemblies, and in general this could be in general Design and Layering and/or taking project structure clean.
1. What are the advantages of separating Solutions/DLL?
The advantage of separating solutions and assemblies in general is related to a Design Approach, a code reuse and layers organization, as said, separating solutions helps to share objects/components and to distribute the responsability between layers, promote multi target and pluggable solutions (see for example various storage target assemblies (Database, Files, etc)), testability
2. What are the disadvantages of separating Solutions/DLL?
The major disadvantages, as others said before me, are, first of all complexity (management, maintenance), then performance (but this is another discussion, it's not easy as saying that)
3. If I create a new solution/DLL for every shareable resource isn't going to be lots of solutions?
It depends, first of all I think this could depend on design choiches
4. After too many solutions (like 40+) is this going to have some bad effects of IDE performance (VS.NET 2008)?
I'm not so sure about performance degradation in VS2008 IDE, but sure it could affect performance to manage a single solution of 60+ projects than for instance 4 solutions with 20 projects each.. It must be clear that VS IDE performance could be degraded even after opening for instance 35 files together just from a single or double project solution..
At the end I think the BIG thng to take i mind is that it's better to "build" just what it's really needed than fall in an over-design for instance, so when things became too complex to manage (to many projects) it's better to stop and think "everything's going well?"
170
In general I suggest using at least one DLL (to separate your business logic from your UI), and more if you'll have different versions of your application that might not need all of that code.
*We often make ourselves believe we'll reuse that wonderful Order class. We probably won't. Domain models just tend to be different.
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
