|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
|
Message #229587
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
 |
Don´t be afraid of a large number of assemblies
Although I agree with Patrick on the importance of controlling the dependencies among the different "parts" of a software (methods, classes, assemblies, components, processes) and I like his recommendation to use namespaces to structure code... I disagree with his recommendation to reduce the number of assemblies.
Right to the contrary I think, splitting projects into a larger number of assemblies (or VS2005 projects for that matter) is the number one means to actually make clear and enforce encapsulation.
Assemblies are the material to forge true components of. So whoever believes in component oriented software development, that means wrapping up functionality in binary packages for easy re-use and easier decoupling, should strive for chopping a problem into as many assemblies as necessary - and not as few as possible.
Assemblies (or components consisting of 1 or a few assemblies) should be the focus for every developer. Logical structure arrived at by modelling and design should be reflected by physical structure and work organization. That´s an obvious truth, I´d say. Logical structure that´s not made tangible - and assemblies are more tangible that namespaces - tends to erode. Trying to keep the number of assemblies low during development - and putting many assemblies/VS2005 projects into one or just a few VS2005 solutions - are an invitation to increased coupling.
However, I agree with Patrick that a large number of assemblies might be detrimental to easy deployment or high performance. Fundamentally there´s no difference for the CLR if an application consists of 3, 30, or 300 assemblies. But checking 300 assemblies for completeness while bundling up an application for deployment is harder than checking 3.
So my recommendation is: Distinguish between implementation and deployment. Split code into as many assemblies as seems necessary to get high testability, and productivity, and retain a good structure.
But when it comes to deployment, then merge the many assemblies into just a few depending on runtime requirements to balance performance and memory footprint.
I use ILmerge (http://research.microsoft.com/~mbarnett/ILMerge.aspx) for this purpose all the time without a problem.
-Ralf
http://www.ralfw.de (German)
http://ralfw.blogspot.com/ (German)
http://weblogs.asp.net/ralfw/
http://object-relational-mapping.blogspot.com/
|
|
|
Message #229610
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Need 4 Speed
I work in an environment in which lower product development time/competitive speed to Market is paramount. To meet these objectives, we support parallel software development but unfortunately without the use of branching. This means that a single Assembly –being the smallest deployable unit- has the potential of turning into a dependency bottleneck within our development process. As you may already be aware, the problem arises when two or more pieces of work need to be concurrently performed on files that reside within the same class library or assembly. Of course, allowing both pieces of work to proceed would result in a dependency –both work items will need to be released at the same time – thereby impacting speed to market. Having the option of producing more assemblies certainly alleviates this risk…...
|
|
|
|
Hot threads
Hot threads
Hot threads
|
More hot threads
More hot threads
More hot threads
|
|
Speaking at EclipseCon 2006, Java developer and independent consultant Madhu Siddalingaiah compared Microsoft's Visual Studio IDE to the open source development environment of Eclipse.
(32 comments,
last posted
December 29, 2007)
In this tech talk, Microsoft's Peter Provost talks about the design of the Composite UI Application Block and how the p&p team has led Microsoft in the adoption of Agile methodologies.
(0 comments,
last posted
April 17, 2006)
Chapter 4 of Framework Design Guidelines, titled "Type Design Guidelines," presents patterns that describe when and how to design classes, constructs and interfaces. In this chapter, Abrams and Cwalina divide types into four groups and discuss the do's and don'ts of type design.
(2 comments,
last posted
July 07, 2006)
Paul Ferrill caught up with prime open-source .NET applications driver Miguel De Icaza at Novell's BrainShare conference last week. They discussed the status of Windows Forms for Mono (it's coming along) and VB.NET for Mono (it looks like it's out).
(5 comments,
last posted
March 30, 2006)
In this tech talk, Microsoft Visual Studio architect Jack Greenfield discusses the company's approach to Domain-Specific Languages, or DSLs, and the part they play in software factories.
(0 comments,
last posted
March 15, 2006)
More hot threads »
|
|
