Patterns Explained


I have continually repeated in my ranting about employing sound design techniques that the use of good design transcends any technology. The use of patterns is just that kind of " transcendental experience" (apologies to Karl Rahner) you can utilize to enforce sound design principles in any technology, including .NET. Given enough time and experience, every developer, consultant, or similar professional vein has been through the gamut of providing a great solution they have known they have seen before. Maybe they've even provided the same solution but with different tools and technology. Those folks may now understand that when it comes to design, a good design is a good solution, despite the technology. No matter how good the technology may be, it is only as good as its design and specifically the implementation of it. In fact, a great design with older technology may still be good, but a bad design with good technology is usually just bad.

Table 1.2. An overview of .NET and its major selling features over other platforms

Interoperability support (Interop)

Migrating to .NET from existing languages and platforms has been made much easier. Especially if that environment is COM or Java. COM, Interop is built into the framework, and C# will be very familiar for those developing in Java currently. In fact, Microsoft has a migration utility to automatically migrate existing Java source code into C#.

Common language runtime ( CLR )

This is the engine that is shared among all languages supported in .NET, including C#, VB.NET, Managed C++, J#, and others to come.

With the help of the CLR, the developer can write base classes in VB.NET, child classes in C#, and aggregate this tree from Managed C++ (this is just one example). You choose the language during implementation.

Base class library (BCL)

What makes Java so appealing besides the managed environment and cross-platform support is its class library. The .NET framework takes the class library concept a step further by supporting it across any language and extensible for future platform variances. Now BCL-supported features such as remoting, string manipulation, exception handling, and collection management construct is the same from any language conforming to the CLI.

Common type system ( CTS )

This addresses the supported data types within the framework and how they are represented in metadata format. Each supported .NET language need only support a subset of the total data type set. Typically, it will be those types used most frequently (e.g., integer, short, long, string, char, boolean, object, interface, struct, etc.)

Simplified deployment

Say goodbye to DLL hell and the nightmare of Windows registration. Applications can now be deployed by a simple XCOPY of the assemblies, ASP.net files, and configuration files.

Full Web service and SOAP support

Complexities are optionally hidden for building Web service providers and consumers in .NET. Details of the syntax and protocol surrounding XML Web services can be fully customized if needed, however. It is truly the best of both worlds .

XML at the core

Serialization, streaming, parsing, transforming, and schema support are only some of the "baked-in" XML features of the .NET runtime.

Object-oriented ASP.NET

Use script for your clients , not your server-based code! Leverage your existing OO framework from ASP.NET and enjoy improved Web application performance due to compiled server code.

Many developers have used sample code or specific snippets of implementation to ease the pains of beginning development. The implementation of that code may or may not be generically repeatable but it provides you with a starting point. It provides a reference from which to remorph the existing code into something completely different. Patterns provide this aspect to an architecture or design and usually at the object level. But that does not mean they couldn't be deployed at other levels.

Patterns are repeatable and named ideas that that can be applied to a design, architecture, or implementation. This means more than just traditional design patterns of repeating a set of prearranged classes forming an object hierarchy. It can apply to any elements, some of which may be technology-specific . This doesn't mean that patterns should not be technology- agnostic . In fact, those that do transcend technology are considerably more useful in a designer's career. However, there may be elements of the pattern that leverage a particular technology's strong suit. As already mentioned, I will be presenting this form of technology leveraging when we get into some implementation and architecture patterns later on. Hopefully, I will provide you with all of the above ”design patterns that transcend .NET, implementation patterns that predicate themselves on technology, and architectural patterns that do both.

Later, I will delve deeper into what patterns are, how they can be categorized, and how they are presented in this book. Along the way, I also give brief primers of the essential elements of object orientation so that this book can stand on its own without sifting through other references. How do you make tangible a design that is intangible yet very repeatable? How do you come up with something you've done before or even what others have done before but maybe in a new way (hint: or with a new technology)? If you are thinking to yourself, UML, you are close but not quite. UML helps but it really only contains the hieroglyphics (or language) you may need to convey your design. It is the standardized and fossilized assemblage of those UML symbols we need. Enter design patterns.

Challenge 1.5

What is the difference between an implementation pattern, an architecture pattern, and a design pattern?

Keep reading.



.NET Patterns. Architecture, Design, and Process
.NET Patterns: Architecture, Design, and Process
ISBN: 0321130022
EAN: 2147483647
Year: 2003
Pages: 70

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net