460 likes | 597 Views
.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. Agenda for the Day.
E N D
.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
Agenda for the Day • 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
Best architecture design Users Presentation Business Logic Data Tier
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 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…
Design Patterns • 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 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
Design PatternsFull 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
Design PatternsFull 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
Design PatternsFull 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
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 QuoteManagerGetInstance() { if (_Instance==null) { _Instance = new QuoteManager (); } return _Instance; } } NOTE: This kind of Pattern is said as “Singleton Pattern”
Our Focus – Distributed Application Design 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?
Services n Integration ?s 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 What are services? # Conceptually, 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
Services n Integration ?s 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
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?????
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
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
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
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
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 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.. ShowProducts() { // Code to // get product // data } Controller
A Small Scenario CustomerManagement Inventory Management CustomerWebPages Utility Quote WebPages Quote Management Price Engine ADO.NET QuoteDataAccess 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?
Solution Scenario Quote Presentation Layer Quote Business Layer Quote Data Access Layer CustomerManagement Inventory Management CustomerWebPages Utility Quote WebPages Quote Management Price Engine ADO.NET QuoteDataAccess The solution could be as.. .. .. .. Can you rearrange any?
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
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)
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)
Process Components A standardized specification that improves the integrity, confidentiality and security of Services Bill Gates LasVegas, Niveda, Jan 5th 2005
UP Components 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 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
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
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