Complexity and Redundancy

Unfortunately, there is no single design strategy that is right for all situations. This is due to the competing needs in software design to eliminate excessive redundancy and excessive complexity.

You can start with a simple page that contains embedded script, and soon the business logic is repeated across files, making the system difficult to maintain and extend. You can move this logic into a set of collaborating components to eliminate redundancy, but doing so adds complexity to the solution. Instead, you can start off with a framework that offers tag libraries, dynamic configuration, and command dispatchers, but although this eliminates redundant code, it adds a great deal of complexity to the system, often unnecessarily.

Adding complexity obscures your intentions, making the system more difficult for other developers to understand. The added complexity also makes the system harder to maintain and extend, thereby increasing the total cost of ownership. If this added complexity is carefully considered and reserved for meeting current requirements, it can be worthwhile. Extra complexity is sometimes added based on speculation that it might be needed someday, rather than based on current requirements. This can clutter code with unnecessary abstractions that impede understanding and your ability to deliver a working system today.

So, again, how do you wade through the choices to arrive at an appropriate Web presentation design strategy for your application?

First, it is important to understand the key Web application design issues, possible solutions, and the associated tradeoffs. This chapter gives developers a strong head start down that path. In the process, you will become familiar with options, assess tradeoffs, and then pick the least complex solution that meets the application’s requirements. Think carefully before choosing a more complex solution that supports possible future change scenarios over a simpler solution that meets today’s requirements. Sometimes the extra cost is justified, but quite often it is not.

Enterprise Solution Patterns Using Microsoft. NET 2003
Enterprise Solution Patterns Using Microsoft. NET 2003
Year: 2004
Pages: 107 © 2008-2017.
If you may any questions please contact us: