Practical Enterprise Application Development

Agenda
Introduction
Enterprise Architecture and Design
What is Bad Design?
Good Design Principles for Enterprise Development
Single Responsibility Principle
The Open Close Principle
Dependency Inversion Principle
Demo: Applying Principles

Introduction
Why we are here?
From Project development to Product development
As we build framework on these principles
We want you to start taking care of them
To achieve our vision we need to strive for it

Enterprise Architecture
“Enterprise Architecture is typically used to describe an organization-wide framework for portraying and incorporating the business processes, information flows, systems, applications, data and infrastructure to effectively and efficiently support the organization needs.”

Enterprise ArchitectureDeveloper’s point of view
Defining a process, framework and set of patterns to design, develop, build and maintain all the software that an organization
Unified development platform for creating all elements of software at all levels of design
The reusable elements can then be used to geed or drive other applications with similar need
Defining solid foundation of code and practices that eventually facilitate interoperability in the heterogeneous software environment

Enterprise Development
Patterns and practices adopted by programmers endeavoring to implement enterprise architecture
They address five key areas:
Reliability
Flexibility
Separations of Concerns
Reusability
Maintainability

Hold on hold…
One might think that simple, non-enterprise code that delivers a particular feature is identical in value to enterprise code that delivers precisely the same feature?
While enterprise sample might look a bit more complex (only at first), the resulting class or module ultimately provides more reliability or is more maintainable

Bad design is...
Hard to change!
A single change break lots of other code
Rigid
Fragile
Can’t be ‘extended’
Immobile

Good Design Principles
Enterprise development requires a change in methodologies
We are going to look some good design principles now
By core, we take care of two things
Modularity
Loosely Coupled Classes

The Single Responsibility Principle
"A responsibility is a reason to change, a class or module should have one, and only one, reason to change."

The Single Responsibility Principle
“There should never be more than one reason for a class to change.”
Dijkstra’sSoC: Separation of Concerns
Applies on every level of code

BusinessPartnerValidator
BusinessPartner
Validator
DB
Trade
What is wrong here: Changes if DB changes or Business Logic Changes

RefactoredBusinessPartnerValidator
BusinessPartner
Validator
BusinessPartner
Source
Trade
DB
What's its job?
Classes must have an identifiable single responsibility.

The Open Closed Principle
“Software Entities (Classes, Modules, Functions, etc.) should be open for extension, but closed for modification”

Modules that conform to the open-closed principle have two primary attributes
Open For Extension
behavior of the module can be extended
Closed for Modification
The source code of such a module is inviolate
The normal way to extend the behavior of a module is to make changes to that module. How can these two opposing attributes be resolved?

Abstraction is the key to achieve it
Server
Client
Closed Client

Abstract Server
Client
Server
Open Client

Liskov Substitution Principle
“Functions that reference a base class must be able to use objects of derived classes without knowing it."

Dependency Inversion Principle
“High level modules should not depend upon low level modules. Both should depend upon abstractions. “
“Abstractions should not depend upon details. Details should depend upon abstractions.”

BusinessParty Validator
Introduce stability with abstraction
High Level (Less Stable)
BusinessParty
Source
BusinessParty
Validator
Trade
DB
Low Level
(More Stable)

Better BusinessPartner Validator
<Interface>
IBusinessPartnerSource
BusinessPartnerValidator
BusinessPartySource
Trade
DB

Extensible BusinessParty Validator
<Interface>
IBusinessPartnerSource
BusinessPartyValidator
Trade
WSBusinessPartnerSource
DbBusinessPartySource
DB
Cloud

Let’s Do It
DEMO

Reference and Further Learning
Professional Enterprise .NET
Jon Arking and Scott Millett
Combating Software Entropies with Design Principles and Patterns at Tech-Ed ME
HammadRajjoub
ObjectMentor.com
http://www.objectmentor.com/resources/articles/
Practices and Patterns on MSDN
http://msdn.microsoft.com/en-us/practices/default.aspx

http://www.adilmughal.com	210
http://www.slideshare.net	11
http://www.lmodules.com	2
http://static.slidesharecdn.com	1
http://localhost	1

Practical Enterprise Application Development

by Adil Mughal on May 14, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 225

Statistics

Practical Enterprise Application Development — Presentation Transcript