31,19 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
In Detail
Application architecture is an essential skill for ASP.NET developers. It is always tempting to jump in and start coding, but planning your architecture early in the project will leave you with a solid application that scales well, is easy to modify and extend, and saves you time and effort later on. As businesses struggle to control their costs, writing solid code that can be extended easily is becoming even more important.
This book takes a pragmatic approach to Application Architecture in ASP.NET 3.5. It presents a series of common architectural models, and shows how to select the best ones for your project and apply them.
The book begins by showing you how to use the main architectural models in your applications. You will see how to implement n-tier architectures, MVC, design patterns, and more. But this is no software engineering theory book, it is a practical, hands-on guide that shows you how to use these techniques in your software straight away. We then go on to build SOA (Service-Oriented Architecture) applications with the Windows Communication Framework (WCF). Finally the book contains some essential guidance on effective database design, and a chapter on localizing your applications.
This book is a great way to learn ASP.NET Architecture in a practical, hands-on way. It will also serve as a quick reference for improving your application design.
This book will show you how to develop better web applications in ASP.NET with strong focus on practical aspects of architecture and design.
Approach
This is a practical hands-on book with clear instructions and lot of code examples. It takes a simple approach, guiding you through different architectural topics using realistic sample projects.
A single project is implemented using different architectural styles to make the reader understand the details of each style. There are also many small independent code samples to explain design patterns, WCF, and localization.
Who this book is for
This book is for people familiar with the ASP.NET framework using either C# or VB.NET. You don't need to be an ASP.NET guru, the book is ideal for novice and intermediate developers.
If reading about application architecture usually confuses you or sends you to sleep, then this book will be perfect for you! In short, any ASP.NET programmer who is confused or disoriented reading different books or materials on architectures wondering how and what to implement in their application, will definitely benefit from this book!
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 293
Veröffentlichungsjahr: 2008
Ähnliche
Table of Contents
ASP.NET 3.5
Application Architecture and Design
Vivek Thakur
ASP.NET 3.5
Application Architecture and Design
Copyright © 2008 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: October 2008
Production Reference: 1171008
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847195-50-0
www.packtpub.com
Cover Image by Nilesh Mohite (<[email protected]>)
Credits
Author
Vivek Thakur
Reviewers
Jerry Spohn
Ian Robinson
Tim Eisenhauer
Acquisition Editor
Adil Rizwan Ahmed
Development Editor
Ved Prakash Jha
Technical Editors
Rakesh Shejwal
Shadab Khan
Editorial Team Leader
Akshara Aware
Project Manager
Abhijeet Deobhakta
Project Coordinator
Lata Basantani
Indexer
Monica Ajmera
Proofreader
Dirk Manuel
Copy Editor
Sumathi Sridhar
Production Coordinator
Shantanu Zagade
Cover Work
Shantanu Zagade
About the Author
Vivek Thakur is passionate about architecting and developing applications based on the Microsoft .NET platform using ASP.NET, C#, VB.NET, and MS AJAX. He has authored several technical articles on ASP.NET and has also been an All-Star-level contributor on the ASP.NET forums. Vivek's passion for ASP.NET has been formally recognized by way of the Most Valuable Professional (MVP) award given to him by Microsoft in April 2007, and again in 2008. He is also a Subject Matter Expert for Microsoft ASP.NET 3.5 Certification Exams. He is a leading contributor and moderator in the CodeAsp.Net forums. Vivek is currently working as the Managing Partner in Axero Solutions LLC, a US-based software product development and business consulting firm.
Although his expertise lies in Microsoft's .NET platform, Vivek is also knowledgeable on J2EE and C/C++. He has a deep interest in programming, chaos theory, and artificial intelligence, and is a strong advocate of chaos theory in software systems and management.
Besides his love for software architecture and design, Vivek also focuses on project management skills and has substantial experience in managing small to medium sized projects. He has also conducted numerous training sessions and provided concept-based tutoring for different software firms across India.
Vivek received his Bachelors degree in engineering from the Indian Institute of Technology (IIT), New Delhi, India.
Writing this book would not have been possible without the support of my family and friends. My sincere gratitude to my mother Sharda Thakur, father G.C Thakur, and my sisters Isha and Shikha Thakur for their continued support and encouragement while I was writing this book. Special thanks to my friend Kritika Srinivasan for her incessant support throughout.
I would like to acknowledge Tim Eisenhauer for his extended support while technically reviewing the book, and also for his extended efforts in discussing and providing feedback on many topics.
I would like to thank Ian Robinson and Jerry Spohn for their relentless efforts in technical reviews and making sure that I do not miss out on core technical issues. Thanks to Ved for his detailed feedback and help in solving basic queries.
Also, many thanks to our technical editors Rakesh and Shadab, and our Production Coordinator Shantanu.
About the Reviewers
Ian Robinson is a Software Developer at Engage Software. Originally from Southern Illinois, Ian moved to the St. Louis, Missouri area in 2001 to attend Webster University. After a stint as an intern at a large St. Louis based corporation, Ian graduated with a degree in Computer Science and subsequently joined the team at Engage Software, where he enjoys developing web-based solutions for clients, as well as developing commercial modules for DotNetNuke. Focusing primarily on development within the DotNetNuke web application framework, Ian has notably developed enterprise-level solutions for businesses in the healthcare and mobile industries. He is also a lead instructor for Engage Software's Official DotNetNuke Training, training businesses and individuals on DotNetNuke administration and development in St. Louis and throughout the United States. Ian Robinson is currently working and living in St. Louis Missouri with his wife Lucy.
Jerry Spohn is a Manager of Development for a medium-sized software development firm in Exton, Pennsylvania. His responsibilities include managing a team of developers and assisting in architecting a large, multi-lingual, multi-currency loan account system, written in COBOL and JAVA. He is also responsible for maintaining and tracking a system-wide program and database documentation web site, for which he uses DotNetNuke as the portal for this information.
Jerry is also the owner of Spohn Software LLC., a small consulting firm that helps small businesses in the area of maintaining and improving their business processes. This includes helping with the creation and maintenance of web sites, general office productivity issues, and computer purchasing and networking. Spohn Software, as a firm, prefers to teach their clients how to solve their problems internally, rather than require a long-term contract, thereby making the business more productive and profitable in the future.
Jerry currently works and resides in Pennsylvania, with his wife, Jacqueline, and his two sons, Nicholas and Nolan.
Tim Eisenhauer has 11+ years of website architecture and development experience with a focus on usability design, user interface, and web engineering. Tim is skilled in creating state-of-the-art GUI designs for the ASP.NET platform, built for SEO optimization design, along with a pure-CSS design structure. Tim also has practical hands-on experience in developing content management systems, CRM, ERP, innovative web design ideas and SEO friendly web applications. He also specializes in branding and marketing consulting to help Web 2.0+ businesses succeed and strengthen their position in the extremely competitive e-commerce, B2B, and B2C markets.
Tim has strong exposure to linking creativity and usability with ever changing modern day business scenarios. Strong visual branding and sharp reasoning skills coupled with in-depth technical know-how places Tim amongst a rare breed of technical leaders who can not only help shape businesses up from ground-zero but also help them stand distinctly apart from the crowd.
I dedicate this book to my grandparents Sh. Roop Chand Thakur and Smt. Nirmala Devi.
Preface
The world of web development, as we see today, has undergone many dynamic changes shaped by multiple new technologies and platforms. Over the last few years Microsoft ASP.NET has quickly evolved to become one of the most famous platforms for developing web-based solutions. Since early 2002, when the first version (1.0) of ASP.NET was released, Microsoft has continuously added many out-of-the-box features and components, making web development easier for the end developer. In a very short time span, the ASP.NET platform has grown and matured into a stable object-oriented framework, with a large set of useful tools and a huge class library, attracting widespread interest in the developer communities around the world. With the introduction of LINQ, MS AJAX, WCF, WPF, and a lot of exciting new tools, the .NET framework has not only grown large but also flexible, in terms of the choices and options being offered to the developers.
With all of these new technologies hogging the limelight, an ever-increasing gap was created in the mindset of new developers, due to a shift in priorities. Developers, especially beginners, were attracted by the buzz created by these new,cool tools, and started interpreting them as a solution for better architecture and design, losing focus on the core concepts in the process. A developer, who has just learnt the basics of ASP.NET, was more eager to devote his or her time to technologies such as AJAX and LINQ instead of learning and implementing design patterns.
One reason for this paradigm shift was the lack of books that could showcase a better way to structure and develop ASP.NET-based web solutions, explaining with examples how to use different architectural styles and design patterns in real-life ASP.NET code. This book aims to bridge that gap.
I won't be focusing on deep and detailed theoretical concepts, as this book is not a "pure" architecture and design guide. Rather, the goal is to show you how to design a web site in ASP.NET the correct way, focus on different design options, analyze and study what architectural options we have, and decide when to use which architectural solution. It is very important to understand that there is no one perfect or best way in architecture and design. We need to improvise, and adapt to each project's unique requirements. Understanding core application architecture and design patterns can be tough for many developers, and so this book aims to elucidate these through the use of real-life examples and code in ASP.NET. This book will also shed some light on the basics of better application structure, coding practices, and database design, and will demonstrate, with suitable examples, how the correct architectural decisions can greatly impact overall application stability and performance.
What This Book Covers
Chapter 1 will introduce you to architecture and design in ASP.NET, including tiers, layers, and logical structuring.
Chapter 2 discusses the advantages and disadvantages of using the simplest and easiest 1-tier, 1-layer default architecture in ASP.NET. You will also understand when and why we should use out-of-the-box data source controls, and how the 1-tier, 1-layer style is tightly-coupled and is not flexible or scalable.
Chapter 3 discusses what an ER diagram is, the domain model, the basics of UML, and what an n-layer design is, and how it increases the flexibility and maintainability of the code when compared to a 1-layer architecture. A sample project is explained with code in a 3-layer model. The drawbacks or limitations of this model are also discussed.
Chapter 4 talks about n-tier architecture in ASP.NET and how to implement it. It also explains Data Transfer Objects and how to use them with 4-tier and 5-tier web solutions.
In Chapter 5, you will learn and understand what MVC design is, and how the ASP.NET MVC framework helps us quickly implement MVC design in our web applications.
In Chapter 6, you will learn how and when to use the most common design patterns in ASP.NET: Factory, Dependency Injection, Singleton, and others.
Chapter 7 explains why we need SOA, explaining the advantages of SOA for a beginner. A sample project using SOA architecture is discussed. The chapter also explains how the Windows Communication Framework (WCF) compliments SOA.
Chapter 8 deals with the importance of a well-designed database, balanced normalization, logical and physical models, and tips and tricks for better database models.
Chapter 9 covers localization for ASP.NET applications, the deployment of localized applications, the localization framework, and best practices.
What You Need for This Book
Readers should be familiar with and know how to use:
Who is This Book For
Readers must have basic understanding of the ASP.NET framework, and programming knowledge of either C# or VB.NET. The book can be used by any ASP.NET developer. Although it is primarily aimed at beginner and intermediate developers, it is a good resource for experienced programmers as well. This book is not a theoretical guide on architecture and design patterns, or any other technology.
If reading about application architecture usually confuses you or sends you to sleep, then this book will be perfect for you! In short, any ASP.NET programmer who is confused or disoriented after reading different books or materials on architectures, or is wondering how and what to implement in their application, will definitely benefit from this book!
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "We are just calling the GetAllProducts() method, which has all data access code wrapped in a different class named DAL."
A block of code will be set as follows:
New terms and important words are introduced in a bold-type font. Words that you see on the screen, in menus or dialog boxes for example, appear in our text like this: "In the Internet Explorer, we can change the default language by going to Internet Options and clicking the Language button under the General tab."
Note
Important notes appear in a box like this.
Note
Tips and tricks appear like this.
Reader Feedback
Feedback from our readers is always welcome. Let us know what you think about this book, what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply drop an email to <[email protected]>, making sure to mention the book title in the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Customer Support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the Example Code for the Book
Visit http://www.packtpub.com/files/code/5500_Code.zip to directly download the example code.
Errata
Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in text or code—we would be grateful if you would report this to us. By doing this you can save other readers from frustration, and help to improve subsequent versions of this book. If you find any errata, report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to the list of existing errata. The existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide the location address or website name immediately so we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with some aspect of the book, and we will do our best to address it.
Chapter 1. Introduction to Architecture and Design
Almost every software developer I know is fascinated by software architecture and design. High-level architecture and design patterns are concepts that beginner developers least understand. For most of us, programming is relatively easier to learn; usually good aptitude and decent logical skills are enough to be a good programmer. But architecture is altogether a different beast to handle. It is more of an art, and usually takes years of experience to master.
In this chapter, we will focus on:
Software Architecture
There are many different definitions of software architecture scattered across the web, in reference materials, and in books. In the wide world of programming, many of the definitions you may find are most likely going to be extremely technical in the language they use, and can be difficult for a beginner to fully grasp and understand. There are even places on the web that list thousands and thousands of different definitions by leading software architects, engineers, doctors, philosophers, and professors. (Reference: http://www.sei.cmu.edu/architecture/community_definitions.html).
To begin with, let's start with a technical definition:
Software architecture is an abstraction, or a high-level view of the system. It focuses on aspects of the system that are most helpful in accomplishing major goals, such as reliability, scalability, and changeability. The architecture explains how you go about accomplishing those goals.
Now we will translate this definition into something simple, generic, and easy to understand:
To elaborate more on the "blueprint" part, let us try to understand software architecture with a simple analogy—the process of casting.
Casting is a manufacturing process in which a liquid material is poured into a mold that contains a hollow cavity of a desired shape. The liquid is then allowed to cool and solidify, taking the shape of the mold it was poured into. The mold is the guide that shapes the liquid into the intended result. Keep in mind that the mold can be of any shape, size, or dimension, and is separate or unrelated to the liquid that is poured in.
Now, think of software architecture as the mold and think of your project as the liquid that is poured into this mold. Just like casting, software architecture is the guide that shapes your project into the intended result. The architecture of a software system has no strict relation to the actual code that is written for this system. The architecture simply makes sure that the development process stays within certain defined limits.
Software Design
Software design refers to the thought process involved in planning and providing for a better solution during problem solving. Software design comes after the architecture is decided upon. Architecture is more closely related to the business needs of the project, and theoretically it does not concern the actual technology platform (such as J2EE or Microsoft .NET or PHP) on which the application will be built (although practically we can decide the platform either in parallel with working on the architecture of the application or before doing so). Software design deals with the high-level concepts related to the actual implementation of the architecture in our projects, which include tasks such as usability studies to make sure our project targets the right kind of users, deciding which design patterns to use to make our application scalable, secure and robust. During the design phase, we also decide on the implementation methodology to be used in the actual development phase (which comes after design and involves actual coding). The following diagram shows how architecture and design fit together and relate to each other:
As we can see in the diagram, the actual business requirements and scope of the project are the deciding factors when working on the application architecture. Software design and development come next and, based on the design, the actual development work gets executed. A single problem can have many possible solutions, some of which will be more efficient than others. Before a developer starts chunking out code for a particular business requirement, it would be prudent and beneficial to give some thought and select the best approach from the possible list of options to assure that code performance, scalability and maintainability is not sacrificed in the long run.
In order to understand all of this by way of a simple analogy, consider a car manufacturing plant as an example. The mechanical engineers developing the high-level blueprint of the car would be the architects, and the blueprint itself would be the architecture of the car. This blueprint would include high-level specifications such as:
So the blueprint would specify the limitations as well as the conditions that need to be fulfilled for any design of that car, and besides the blueprint there would be additional constraints such as the budget for the production costs. But this blueprint would not include details of how exactly the engine would be designed, what quality of steel would be used, what type of tires would be used, what type of plastics would be used for the dashboard and other parts, and so on. All of this would actually be decided by the design engineers, who will make sure that their choices fit the blueprint specifications in the best possible way. The engineers will also consider production and design techniques that other car companies might have followed, so that they don't re-invent the wheel.
The actual assembly line production will follow the designs and techniques specified by the engineers and will involve tasks such as cutting metal, choosing the right machines, assembling the individual components, painting, safety tests, and so on, to create a complete working car. The following figure will correlate this example with the equivalent aspects of software development:
From the figure we can see how the car company example loosely translates to software architecture, design, and development. Now let us take another analogy, this time more closely related to the software industry. Consider a company that needs to build a bulk emailing program for its social networking website. A software architect will first understand the high-level requirements of the program, such as:
Based on the answers to the above questions, the architect will come up with an application architecture which covers all aspects of the actual business needs. The architecture will decide how the emailing program should be developed: a Windows Service, or a Web Service, or a console utility, or some batch program run by a scheduler.
But the architecture would not include details such as:
That's the part where design comes into the picture. The application architecture would define limits and boundaries within which the design would move around and improvise. So the architecture would neither go deep into the nitty-gritties of the design phase, nor would it dictate implementation guidelines and programming rules, as the architecture has no relation with programming at all. In fact, the architecture lays out specifications which are more aligned with business requirements, and makes sure that all business aspects are met and taken care of.
Coming back to our bulk email program, the term software design can be loosely translated into the process of designing the actual program, which involves using specific programming techniques (or design patterns, which we will study later) and laying out the basic solution framework. All coding would actually occur within that framework. We can have multiple design options for the same architectural specification, and it is up to the stakeholders to decide which one to go for, considering the overall efficiency and budget constraints.
Here is a simple diagram illustrating the basic process:
Architectural Styles
With time, some of the famous and widely used approaches and techniques among the architects have been grouped together into architectural styles. A particular architectural style represents the interaction and behavior pattern between the system and its components, along with a particular layout and structure. Some famous architectural styles are:
There are many more styles, and each style can be customized to suit individual project needs. We will learn more about some of these styles in the coming chapters, along with some practical examples. It is very important to understand the concept, approach, and effective implementation of a style so that we can decide when to use which style in our own applications. One can even create a new style by combining any of the existing styles and customizing it to achieve greater efficiency and adaptability.
Architecture and Design in ASP.NET
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
The above quote (taken from No Silver Bullet—essence and accident in software Engineering, Brooks, F. P.) aptly highlights the fact that technological improvements can only be stepping stones instead of being silver bullets to solve all architectural and design problems in one go. The ASP.NET platform has rapidly gained a foothold in the web development industry. One of the major factors in favor of ASP.NET, compared to JAVA or PHP, is the excellent integration of the Microsoft IDE, Visual Studio, with the framework. The VS IDE has evolved, complementing the framework itself, with time-saving features such as detailed intelligence support, debugging assistant, and code complete, to list a few. Also, Microsoft has been aggressively adding different tools and technologies, enhancing the overall developer experience. AJAX, LINQ, WCF, WWF and SilverLight have not only stirred up the development world but have also left many developers confused and wondering as to how good these new technologies are, and how they can maximize their productivity by using them.
Note
Some developers strongly feel that these new technologies are coming along much faster than they can be absorbed. There have been many heated debates on the extra aggressiveness with which Microsoft is releasing new products. In many of the offline discussions we have had upto now, most people feel that developers are not getting enough time to absorb existing technologies and "keep pace with MS". People are still struggling with master pages and partial classes, and we have AJAX, SilverLight, WPF, etc.!
Many developers feel that there is simply too much to grasp in too little time, considering the fact that many clients are still using VS2003 and are refusing to upgrade due to reasons such as lack of funds, apprehension of going with new and untested technologies such as WPF and Silverlight, lack of experienced programmers, and so on. Some customers are also confused and are not sure how these new technologies can benefit their business!
We should understand that none of the new technologies were created to be "silver bullets". They have been added to give developers options to chose from, to reduce development time, and to be more effective. These technologies should be used in the right architectural context instead of blindly following them, which can lead to a greater risk through poor implementation. All changes are good, but we need to understand why the change is needed and how it will help us in balancing the advantages and disadvantages.
We have thousands of books, online articles and tutorials on how to use AJAX, LINQ, WWF, and WPF in ASP.NET, but there are still very few online articles and limited books that focus on what architecture to use, and in which ASP.NET application. Because each project is unique in its own way, we can never use a copy-paste solution. The important thing to bar in mind when learning application architecture and design is that there are no strict rules, only guidelines. And these guidelines were developed based on the experience gained over years of work by developers on different projects.
Upcoming latest technologies should not be mistaken as the means to develop better applications. Lets go back to the pre-ASP.NET years for a moment. In those days, classic ASP was very famous. There were many big, famous, and stable applications in classic ASP 3.0. It was difficult to create an object-oriented application with classic ASP (compared to the intuitive way, in which we can do it so easily now in ASP.NET), but good programmers used classes in ASP as well, adopting elements of object-oriented re-usable design. A better platform, such as ASP.NET, did help in building websites that could support a better architecture, but the power to use it in an efficient way still lies in the hands of an experienced programmer.
Just as ASP.NET was a major stepping stone in web development, AJAX enhanced the UI experience along the same lines, providing a user-friendly experience while browsing websites, and LINQ was introduced to revolutionize data access. But still there are numerous robust and popular websites in ASP.NET not using any of the new technologies. This means that the key to building a good website can never only be learning and absorbing the latest technology out there, but also how you put it to use—how you make these technologies work for your project in a comprehensive way.
If one knows how to write clean and maintainable code and use efficient programming techniques to create a good stable architectural platform and application structure, then technology will supplement the design. Without a stable architecture and good coding practices, a programmer might use the technologies in a haphazard manner, creating messy code and junk websites. But once we understand basics of the application architecture and the different design patterns, then these technology tools become our assets.
