Designingapplswithnet

67 %
33 %
Information about Designingapplswithnet

Published on August 7, 2007

Author: Chakravarthy

Source: slideshare.net

Description

This presentation will help you to understand the best design methodologies that are used in the industry

.NET Solutions DSK Chakravarthy http://dskc.blogspot.com

Who am I? Certified by Microsoft Having hands on all phases of SDLC Conducted sessions for major players of the industry… like … Infosys, Accenture, Wipro, etc., Been a consultant for Project management

Certified by Microsoft

Having hands on all phases of SDLC

Conducted sessions for major players of the industry… like … Infosys, Accenture, Wipro, etc.,

Been a consultant for Project management

Agenda for the Day Application Architecture Design Pattern Services and Integration Component Types Recommendations for Application design Layers Business Data

Application Architecture

Design Pattern

Services and Integration

Component Types

Recommendations for Application design

Layers

Business

Data

Pre Lunch Session Over view of Distributed Application Design Services and Service Integration “?s” General Design Recommendations for Applications and services Designing Presentation Layers UI Components Process Components Prerequisites Architect (s) / Tech Export (s) Team Leader (s) Sr. Programmers with C# in depth

Over view of Distributed Application Design

Services and Service Integration “?s”

General Design Recommendations for Applications and services

Designing Presentation Layers

UI Components

Process Components

Prerequisites

Architect (s) / Tech Export (s)

Team Leader (s)

Sr. Programmers with C# in depth

Best architecture design Users Presentation Business Logic Data Tier

Users

Presentation

Business Logic

Data Tier

Design Patterns It describes all the necessary elements and characteristics of the solution in generic language and it forms the basis for any implementation We use the design patterns for To minimize design flaws Performance enhancement Adaptability Scalability Design Patterns should not be confused as a ready made detail of a particular implementation, it’s a template There are almost 26 patterns, which fall in 3 categories…

It describes all the necessary elements and characteristics of the solution in generic language and it forms the basis for any implementation

We use the design patterns for

To minimize design flaws

Performance enhancement

Adaptability

Scalability

Creational : Deals with the problems of the Object construction . Provides flexi approach for 4 Ws (Who, What, Where & When) Structural : Governs how the objects and classes work together Behavioral : Supervise messages sent between the objects Design Patterns Note : The PatternForm is invented by Mr. Christopher Alexander, and he calls them as just “ Patterns ”, but not as “ Design Patterns ” In the current world you’ve around 62 kinds of patterns in practice

Creational : Deals with the problems of the Object construction . Provides flexi approach for 4 Ws (Who, What, Where & When)

Structural : Governs how the objects and classes work together

Behavioral : Supervise messages sent between the objects

Design Patterns Full List AbstractFactoryPattern aka KitPattern AbstractClientPattern ActionPattern aka CommandPattern, TransactionPattern ActiveObjectPattern AdapterPattern aka WrapperPattern AbstractServerPattern ApplicationControllerPattern WrapperPattern aka AdapterPattern BalkingPattern BindingProperties BridgePattern aka HandleBodyPattern BuilderPattern CaretakerPattern ChainOfResponsibilityPattern CommandPattern aka ActionPattern, TransactionPattern CompositePattern CursorPattern aka IteratorPattern DataBusPattern DecoratorPattern aka WrapperPattern Dependents Pattern aka ObserverPattern, PublishSubscribePattern, PubSubPattern DisableJobRequestsWhileRunningJob

AbstractFactoryPattern aka KitPattern

AbstractClientPattern

ActionPattern aka CommandPattern, TransactionPattern

ActiveObjectPattern

AdapterPattern aka WrapperPattern

AbstractServerPattern

ApplicationControllerPattern

WrapperPattern aka AdapterPattern

BalkingPattern

BindingProperties

BridgePattern aka HandleBodyPattern

BuilderPattern

CaretakerPattern

ChainOfResponsibilityPattern

CommandPattern aka ActionPattern, TransactionPattern

CompositePattern

CursorPattern aka IteratorPattern

DataBusPattern

DecoratorPattern aka WrapperPattern

Dependents Pattern aka ObserverPattern, PublishSubscribePattern, PubSubPattern

DisableJobRequestsWhileRunningJob

Design Patterns Full List DoubleCheckedLocking DynamicUserInterfacePattern FacadePattern FacetPattern FactoryMethodPattern aka VirtualConstructorPattern FlyweightPattern FrontControllerPattern GuardedSuspension HandleBodyPattern aka BridgePattern HierarchicalVisitorPattern InterpreterPattern IteratorPattern aka CursorPattern KitPattern aka AbstractFactoryPattern LazyInstantiationPattern MediatorPattern MementoPattern aka Token Pattern MockObjectPattern aka Service Stub Pattern MonostatePattern NullObjectPattern ObserverPattern aka DependentsPattern, PublishSubscribePattern, PubSubPattern PolicyPattern aka StrategyPattern PrototypePattern ProxyPattern aka SurrogatePattern PublishSubscribePattern aka DependentsPattern, ObserverPattern, PubSubPattern PubSubPattern aka DependentsPattern, ObserverPattern, PublishSubscribePattern ReadWriteLock

DoubleCheckedLocking

DynamicUserInterfacePattern

FacadePattern

FacetPattern

FactoryMethodPattern aka VirtualConstructorPattern

FlyweightPattern

FrontControllerPattern

GuardedSuspension

HandleBodyPattern aka BridgePattern

HierarchicalVisitorPattern

InterpreterPattern

IteratorPattern aka CursorPattern

KitPattern aka AbstractFactoryPattern

LazyInstantiationPattern

MediatorPattern

MementoPattern aka Token Pattern

MockObjectPattern aka Service Stub Pattern

MonostatePattern

NullObjectPattern

ObserverPattern aka DependentsPattern, PublishSubscribePattern, PubSubPattern

PolicyPattern aka StrategyPattern

PrototypePattern

ProxyPattern aka SurrogatePattern

PublishSubscribePattern aka DependentsPattern, ObserverPattern, PubSubPattern

PubSubPattern aka DependentsPattern, ObserverPattern, PublishSubscribePattern

ReadWriteLock

Design Patterns Full List ScheduledTask SchedulerPattern SeparatedInterface Pattern aka InterfaceSegregationPrinciple ServiceStubPattern aka MockObjectPattern SingletonPattern StatePattern aka StatesPattern StatesPattern aka StatePattern StaticUserInterfacePattern StrategyPattern aka PolicyPattern SurrogatePattern aka ProxyPattern TemplateMethodPattern TokenPattern aka MementoPattern TransactionPattern aka ActionPattern, CommandPattern VirtualConstructorPattern aka FactoryMethodPattern VisitorPattern

ScheduledTask

SchedulerPattern

SeparatedInterface Pattern aka InterfaceSegregationPrinciple

ServiceStubPattern aka MockObjectPattern

SingletonPattern

StatePattern aka StatesPattern

StatesPattern aka StatePattern

StaticUserInterfacePattern

StrategyPattern aka PolicyPattern

SurrogatePattern aka ProxyPattern

TemplateMethodPattern

TokenPattern aka MementoPattern

TransactionPattern aka ActionPattern, CommandPattern

VirtualConstructorPattern aka FactoryMethodPattern

VisitorPattern

Design Patterns an Example Problem: You are building a Quote Application, which contains a class that is responsible for managing all the quotes in the system. It is important that all quotes interact with one and only one instance of this class. How do you structure your design so that only one instance of this class is accessible with in the application? Solution: A simple solution to this problem is to create a QuoteManager class with a private constructor so that no other class can instantiate it. This class contains a static instance of QuoteManager that is returned with a static method named GetInstance () . Can you design the code for the same?

Design Patterns an Example public class QuoteManger { // NOTE: For single threaded application only private static QuoteManagaer _Instance = null; private QuoteManager () {} private static QuoteManager GetInstance () { if (_Instance==null) { _Instance = new QuoteManager (); } return _Instance; } } NOTE: This kind of Pattern is said as “Singleton Pattern”

We are focusing on distributed applications and WebServices that may need to provide integration capabilities for multiple data sources & services, and they may require a user interface for one (or) multiple devices Our Focus – Distributed Application Design Designing a distributed application involves Making decisions about it’s logical and physical architecture issues Sound knowledge of the technologies and infrastructure used to implement the functionality Should be very much aware of the business process that the application will perform Functional Requirements Levels of scalability, availability, security Maintainability required i.e., Non-Functional, operational, requirements

We are focusing on distributed applications and WebServices that may need to provide integration capabilities for multiple data sources & services, and they may require a user interface for one (or) multiple devices

Designing a distributed application involves

Making decisions about it’s logical and physical architecture issues

Sound knowledge of the technologies and infrastructure used to implement the functionality

Should be very much aware of the business process that the application will perform

Functional Requirements

Levels of scalability, availability, security

Maintainability required i.e., Non-Functional, operational, requirements

Services n Integration Specialisation means not doing the Extraordinary things, but doing Ordinary things Extraordinarily well... So, What are you doing?

As iNet and related technologies grow, and the large organizations seek to integrate their systems across the companies boundaries, a service-based approach to design solutions has evolved Services n Integration ?s  What are services? # C onceptually, they are similar to the Traditional Components  How are they? # They encapsulate their own data and remember, they are not a part of your application, rather they are used by your application  What is the difficulty with services? # They might have built on different platforms by different teams on different schedules and may be maintained & Updated independently Therefore, it’s critical to implement communication between them

As iNet and related technologies grow, and the large organizations seek to integrate their systems across the companies boundaries, a service-based approach to design solutions has evolved

 How do I resolve? # You can implement communication between them by using message-based technologies # You can implement message communication by i) Explicitly – By writing code to send and receive Message Queuing Messages. Ex. MSMQ ii) Implicitly – By using Infrastructure components that manage communication. Ex. A Web service proxy by VS.NET Services n Integration ?s

 How are the services differ from Components? # Services exists in their own trust boundary and manage their own data, out side your application  What is crucial between Services & Application integration? # Establishing a secure, authenticated connection  What should I be aware, while using a service? # The internal implementation is irrelevant to your design # But need to know the business functionality that the service provides # Also the details of the contract you must adhere to in order to communicate with it such as i) Communication Format ii) Data Schema iii) Authentication Mechanism etc., Services n Integration ?s

 What a service contain? # The same kind of components that any traditional application do # You can categorise them as i) Logic Components : That orchestrate the tasks they do ii) Business Components : That implement the actual BL iii) Data Access Components : that access the service’s data store iv) Interfaces : That expose the functionality  What happens when I integrate a service? # Your application will also call other services through “ Service agents ”, which communicate with service on behalf of the calling client application Services n Integration ?s

A small scenario A Retail application This application has an order UI to place orders, this could be either web or non-web This application uses an external Credit Card authentication service to validate the customer’s credit card details and authorise the sale A courier service is used to arrange the delivery of goods Can you give me a Sequence diagram?????

This application has an order UI to place orders, this could be either web or non-web

This application uses an external Credit Card authentication service to validate the customer’s credit card details and authorise the sale

A courier service is used to arrange the delivery of goods

Can you give me a Sequence diagram?????

A small scenario A Retail application Sequence Diagram

Components and Tiers in Application Imagination is more important than knowledge

Distributed design Distributed Application Design means, “You should divide your application into components providing PBD ( Presentation , Business and Data ) Services”. While doing the same follow the below rules. Form the Functional Layers : Group the Components that perform similar types of functions into layer Prepare the Communication Channel : Components in the same layer communicate via Agents, but the communication with “ABOVE “ or “ BELOW” a certain layer use the services 

Form the Functional Layers : Group the Components that perform similar types of functions into layer

Prepare the Communication Channel : Components in the same layer communicate via Agents, but the communication with “ABOVE “ or “ BELOW” a certain layer use the services

Points to Note Layer : Combination of similar component types Tier : Physical distribution pattern # Conceptually, the services can be seen as components of overall solution. # Internally, each service is made up of software components, just like any other application and these components are logically grouped into Presentation / Business Logic /Data Services # While designing the application, follow the below steps 1) ( Can you ) Draw a block diagram for the ( previous ) scenario ! % & $ # ? 2) Explain the bits & pieces of each block as internal elements 3) Finally, prepare a simplified view of any application and it’s layers 4) But remember that, each service encapsulates its own data and manages atomic transactions on it’s own For now, sketch a component design for the previous scenario

Layer : Combination of similar component types

Tier : Physical distribution pattern

Component design A Retail application Component Diagram You might design the one like this . . .

Simplified View Here comes the simplified view of any general application and it’s layers

A Detailed View The previous scenario for the detailed design would look like . . . .

General Design Recommendations for Applications and Services Identify the components that are required and not required Design the components as consistent as possible Understand “How components communicate?” Maintain the “Data Format” consistent for Exchange Follow the code policies Enforce strict Layering System

Identify the components that are required and not required

Design the components as consistent as possible

Understand “How components communicate?”

Maintain the “Data Format” consistent for Exchange

Follow the code policies

Enforce strict Layering System

Tea Break

Components - In detail Knowing the path to failure is as important as Knowing the path to success

Component Types Note : The term component is used in the sense of a piece or part of the overall solution. This includes compiled software components such as Microsoft .NET assemblies, and other software artifacts such as Web pages and Microsoft BizTalk Server schedules

Components In detail User Interface (UI) Components : Use them to render and format data for users and to Acquire and Validate data coming in from them User Process Components : To help the user interactions synchronize with the UI Components , it is a best practise to drive the process using separate User Process Components Business Workflows :These components are used to perform the business process . During the transaction, these process could take an inderminate amount of time to complete, so the required tasks and the data required to perform them would have to be managed Business Components : Regardless of whether a business process consists of a single step or an orchestrated workflow, your application will probably require components that implement business rules and perform business tasks Service Agents : Any business component that needs to use functionality provided by an External service, they many need to provide some code to manage the semantics of communicating with that particular service Service Interfaces : These expose business logic as service that support the communication contracts ( message-based communication, formats, protocols, security etc.,) These are sometimes referred to as Business facades Data Access Logic Components : It makes sense to abstract the logic necessary to access data in a separate layer of DAL Components Business Entity Components : These help Data to traverse between components, they are used internally in every application “Data structures such as DataSets, DataReaders, XML Streams.. Components for Security, Operational Management and Communication : The main purpose of these components to perform Exception management Authorize users to perform certain tasks To communicate with other services and applications

User Interface (UI) Components : Use them to render and format data for users and to Acquire and Validate data coming in from them

User Process Components : To help the user interactions synchronize with the UI Components , it is a best practise to drive the process using separate User Process Components

Business Workflows :These components are used to perform the business process . During the transaction, these process could take an inderminate amount of time to complete, so the required tasks and the data required to perform them would have to be managed

Business Components : Regardless of whether a business process consists of a single step or an orchestrated workflow, your application will probably require components that implement business rules and perform business tasks

Service Agents : Any business component that needs to use functionality provided by an External service, they many need to provide some code to manage the semantics of communicating with that particular service

Service Interfaces : These expose business logic as service that support the communication contracts ( message-based communication, formats, protocols, security etc.,) These are sometimes referred to as Business facades

Data Access Logic Components : It makes sense to abstract the logic necessary to access data in a separate layer of DAL Components

Business Entity Components : These help Data to traverse between components, they are used internally in every application “Data structures such as DataSets, DataReaders, XML Streams..

Components for Security, Operational Management and Communication : The main purpose of these components to perform

Exception management

Authorize users to perform certain tasks

To communicate with other services and applications

Designing Presentation Layers

Windows Desktop User Interfaces Internet Browser User Interfaces Mobile Device User Interfaces Web User Interface Smart Device User Interface Document-based User Interfaces .NET to Office Developers Office ‘n’ .NET Interoperability UI Components & Types

Windows Desktop User Interfaces

Internet Browser User Interfaces

Mobile Device User Interfaces

Web User Interface

Smart Device User Interface

Document-based User Interfaces

.NET to Office Developers

Office ‘n’ .NET Interoperability

Designing UI Components ShowProducts() { // Code to // get product // data } Controller When a user interacts with a user interface element, an event is raised that calls code in a controller function, which inturn calls business components, data access logic components (or) user process components to implement the desired action and retrieve any necessary data..

A Small Scenario You are designing a web-based quote application containing a great deal of business and presentation logic, which, in turn, depends on numerous platform software components to provide a suitable execution environment. How do you organise your system at a high level to be flexible, loosely coupled, and yet highly cohesive? Can you rearrange wrf to Layers? CustomerManagement Inventory Management CustomerWebPages Utility Quote WebPages Quote Management Price Engine ADO.NET QuoteDataAccess

Solution Scenario Can you rearrange any? The solution could be as.. .. .. .. CustomerManagement Inventory Management CustomerWebPages Utility Quote WebPages Quote Management Price Engine ADO.NET QuoteDataAccess Quote Presentation Layer Quote Business Layer Quote Data Access Layer

UI Components UI Components by nature Don’t initiate or participate in transaction Have ref to user process component Encapsulate both view functionality and a controller While accepting input from user UI Components should Acquire proper data from users and assist them via different techniques Capture the events and call controller functions Initiate an action on the current user process o changing data of the current user process Restrict the types of input a user can enter Perform Data Validation Perform simple mapping to values needed by the underlying components to do their work. Ex: You may capture “Product Name”, convert to “ID” Internet user gestures to call a controller functions, such as dragNdrop or button clicks Use a utility component for Caching and Paging

UI Components by nature

Don’t initiate or participate in transaction

Have ref to user process component

Encapsulate both view functionality and a controller

While accepting input from user UI Components should

Acquire proper data from users and assist them via different techniques

Capture the events and call controller functions

Initiate an action on the current user process o changing data of the current user process

Restrict the types of input a user can enter

Perform Data Validation

Perform simple mapping to values needed by the underlying components to do their work. Ex: You may capture “Product Name”, convert to “ID”

Internet user gestures to call a controller functions, such as dragNdrop or button clicks

Use a utility component for Caching and Paging

Windows Desktop – UIs Recommendations When creating a Windows Forms-based application, consider the following recommendations Rely on data binding to keep data synchronized across multiple forms that are open simultaneously Try avoiding hard-coding relationships between forms to make the elements more reusable Implement error handlers (or) exception handlers Validate user input, this validation should occur at the stages of every process that allow point-in-time validations For the custom controls, expose only the public properties and methods that are actually needed Implement controller functions as separate functions. Do not implement controller functionality directly in control events handlers (Look at the example from the book)

Rely on data binding to keep data synchronized across multiple forms that are open simultaneously

Try avoiding hard-coding relationships between forms to make the elements more reusable

Implement error handlers (or) exception handlers

Validate user input, this validation should occur at the stages of every process that allow point-in-time validations

For the custom controls, expose only the public properties and methods that are actually needed

Implement controller functions as separate functions. Do not implement controller functionality directly in control events handlers (Look at the example from the book)

iNET Browser UIs Recommendations When you are implementing an application and publish a Web page-based user interface for a browser, consider the following design recommendations for ASP.NET user interfaces Implement a custom error page, and a global exception handler in Global.asax Use ASP.NET rich validation controls (or) if the user process has a Validate control function, call it before transitioning to other pages to perform point-in-time validation If you are using WebUserControls, expose only the public properties and methods that are actually needed Use ViewState to store page specific state Controller functions should invoke the actions on a user process components to guide the user through the current task rather than redirecting the user to the page directly Implement controller functions as separate functions. Do not implement controller functionality directly in control events handlers (Look at the example from the book)

Implement a custom error page, and a global exception handler in Global.asax

Use ASP.NET rich validation controls (or) if the user process has a Validate control function, call it before transitioning to other pages to perform point-in-time validation

If you are using WebUserControls, expose only the public properties and methods that are actually needed

Use ViewState to store page specific state

Controller functions should invoke the actions on a user process components to guide the user through the current task rather than redirecting the user to the page directly

Implement controller functions as separate functions. Do not implement controller functionality directly in control events handlers (Look at the example from the book)

Process Components A standardized specification that improves the integrity, confidentiality and security of Services Bill Gates LasVegas, Niveda, Jan 5 th 2005

A standardized specification that improves the integrity, confidentiality and security of Services

Bill Gates

LasVegas, Niveda, Jan 5 th 2005

These help the user interactions synchronize with the UI Components , it is a best practise to drive the process using separate User Process Components User process components are typically implemented as .NET classes that expose methods that can be called by user interfaces. Each method encapsulates the logic necessary to perform a specific action in the UP The user interfaces creates instances of the user process component and uses it to transition through the steps of process You should design them with globalization in mind to allow for localization to be implemented in the User Interface Note : User process components co-ordinate the display of user interface elements Task for You : Can you design common ProcessComponent for the previous Retail application ? UP Components

UP Components Example namespace PurchaseUserProcess{ public class PurchaseUserProcess{ public PurchaseUserProcess(){ userActivityID= System.Guid.NewGuid(); } private int intCustomerID; private DataSet dsOrderData; private DataSet dsPaymentData; private Guid userActivityID; public bool webUI; public void ShowOrder() { if(webUI){ System.Web.HttpContext.Current.Response.Redirect("http://www.myserver.com/orderDetails.aspx"); } else{ OrderDetails = new OrderDetailsForm(); OrderDetails.Show(); } } public void EnterPaymentDetails() { // code to display the Payment details page or window goes here } public void ShowConfirmation() { // code to place the order goes here } public void Finish() { // code to go back to the main page or window goes here } public void SaveToDataBase() { // code to save order and payment info in the private variables to a database } public void ResumeCheckOut(System.Guid ProcessID) { // code to reload the process state from the Database } public void Validate() { // code to make sure the process instance variables have the right information for the current step } } }

UP Components Advantages Separating the user interaction functionality into user interface and user process components provides the following advantages Long-running user interactions state is more easily persisted, allowing a user interaction to be abandoned and resumed, possibly even using a different user interface The same user process can be reused by multiple user interfaces

Separating the user interaction functionality into user interface and user process components provides the following advantages

Long-running user interactions state is more easily persisted, allowing a user interaction to be abandoned and resumed, possibly even using a different user interface

The same user process can be reused by multiple user interfaces

UP Components Guidelines for separating a UserProcess from UserInterface Draw Sequence Diagrams – helps you to identify the business process that the UserInterface process will help to accomplish Identify the data needed by the business process Identify additional state you will need to maintain Design the visual flow of the UserProcess UserProcess Component Interface Design

Guidelines for separating a UserProcess from UserInterface

Draw Sequence Diagrams – helps you to identify the business process that the UserInterface process will help to accomplish

Identify the data needed by the business process

Identify additional state you will need to maintain

Design the visual flow of the UserProcess

UserProcess Component Interface Design

UP Design UP “Actions”(1) : these typically trigger a change in the state of UserProcess. One should try to encapsulate calls to business components to these action methods (6) State Access Methods(2) : to acess the business-specific state by using GET & SET properties to expose one value to the business process deals with (5) State Change Events(3) : Fired during the business-related state of the UserProcess changes 4) Control functions that let you start, pause, restart, and cancel a particular user Process(4) : Control methods could load required reference data for the UI from data access logic components (7) or delegate this work to the UI Component that needs the data

UP “Actions”(1) : these typically trigger a change in the state of UserProcess. One should try to encapsulate calls to business components to these action methods (6)

State Access Methods(2) : to acess the business-specific state by using GET & SET properties to expose one value to the business process deals with (5)

State Change Events(3) : Fired during the business-related state of the UserProcess changes

 

Add a comment

Related presentations