MSDN Magazine - March 2008 - (Page 54)

James Kovacs Loosen Tame Your Software Dependencies For More Flexible Apps ew would disagree that striving for a loosely coupled design is a bad thing. Unfortunately, the software we typically design is much more tightly coupled than we intend. How can you tell whether your design is tightly coupled? You can use a static analysis tool like NDepend to analyze your dependencies, but the easiest way to get a sense of the coupling in your application is to try to instantiate one of your classes in isolation. Pick a class from your business layer, such as an InvoiceService, and just copy its code into a new console project. Try to compile it. You’ll likely be missing some dependencies, such as an Invoice, InvoiceValidator, and so forth. Copy those classes to the console project and try again. You’ll likely discover other missing classes. When you are finally able to compile, you may find that you have a significant fraction of your codebase in the new project. It’s like pulling on a loose thread and watching your entire sweater fall apart. Every class is directly or indirectly coupled to every other class in your design. Making changes in this type of system is difficult at best because a change in any one class can have a ripple effect throughout the rest of the system. Now the point is not to eschew coupling completely, as that would be impossible. For instance: string name = “James Kovacs”; Up lihood of the System.String class changing in undesirable ways is very low, as is the likelihood that requirements will change in such a way that would necessitate modifying how I interact with System.String. So I am comfortable with that coupling. The point of this thought exercise is not to eliminate coupling but to be aware of it and to make sure you choose your couplings wisely. Let’s take another example of code often found in the data layer of many applications: SqlConnection conn = new SqlConnection(connectionString); This article uses the following technologies: .NET Framework This article discusses: What’s wrong with tightly coupled architectures ✥Testing and dependency woes ✥ Dependency inversion ✥ Dependency injection ✥ Code download available at: msdn.microsoft.com/msdnmag/code08.aspx James Kovacs is an independent architect, developer, trainer, and jack-of-all trades living in Calgary, Alberta, specializing in agile development using the .NET Framework. He is a Microsoft MVP for Solutions Architecture and received his master’s degree from Harvard University. James can be reached at jkovacs@post.harvard.edu or www.jameskovacs.com. I’ve coupled my code to the System.String class in the Microsoft® .NET Framework. Is that a bad thing? I would argue not. The like54 msdnmagazine http://msdn.microsoft.com/msdnmag/code08.aspx http://www.jameskovacs.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - March 2008

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.