19
Design Patterns for Enterprise Applications Best Practices in development Roy Abarca Miranda Avantica San Carlos, Nov 2013.

Design Patterns for Enterprise Applications

  • Upload
    ham

  • View
    49

  • Download
    5

Embed Size (px)

DESCRIPTION

Design Patterns for Enterprise Applications. Best Practices in development Roy Abarca Miranda Avantica San Carlos, Nov 2013. Design Patterns. “A general reusable solution to a commonly occurring problem within a giv en context in software design .” - PowerPoint PPT Presentation

Citation preview

Page 1: Design Patterns for Enterprise Applications

Design Patterns for Enterprise Applications

Best Practices in developmentRoy Abarca Miranda

Avantica San Carlos, Nov 2013.

Page 2: Design Patterns for Enterprise Applications

Design Patterns“A general reusable solution to a

commonly occurring problem within a given context in software design.”

Is NOT a finished design that can be transformed directly into source or machine code.

A description or template for how to solve a problem that can be used in many different situations.

Best practices that the programmer must implement in the application.

Page 3: Design Patterns for Enterprise Applications

Design PatternsTypes of design patterns (some of them):

Algorithm strategy patterns addressing concerns related to high-level strategies describing how to exploit application characteristics on a computing platform.

Computational design patterns addressing concerns related to key computation identification.

Execution patterns that address concerns related to supporting application execution, including strategies in executing streams of tasks and building blocks to support task synchronization.

Implementation strategy patterns addressing concerns related to implementing source code to support program organization, and the common data structures specific to parallel programming.

Structural design patterns addressing concerns related to high-level structures of applications being developed.

Page 4: Design Patterns for Enterprise Applications

Client-Server

Page 5: Design Patterns for Enterprise Applications

Client-Server

Page 6: Design Patterns for Enterprise Applications

Separation of concerns (SoC)Good design of the architectureSeparate the different areas based on their

responsibilities. The data access layer, the business layer the UI,

services, entities, etc.The goal: design systems so that functions

can be optimized independently of other functions.

Page 7: Design Patterns for Enterprise Applications

Aspect Oriented Programming (AOP)Is a programming paradigm which aims to

increase modularity by allowing the separation of cross-cutting concerns.

AOP includes programming methods and tools that support the modularization of concerns at the level of the source code, while "aspect-oriented software development" refers to a whole engineering discipline.

Page 8: Design Patterns for Enterprise Applications

Aspect Oriented Programming (AOP)AOP is a high level view of SoC.A real example of this could be separate in

different layers the app, for instance UI, BL, DAL, also the cross cutting modules like Exception Handling, Validation.

Page 9: Design Patterns for Enterprise Applications

SOAA software design and software architecture 

design pattern based on discrete pieces of software providing application functionality as services to other applications.

This is known as service-orientation. It is independent of any vendor, product or

technologyA service is a self-contained unit of

functionality, such as retrieving an online bank statement.

Page 10: Design Patterns for Enterprise Applications

SOA

Page 11: Design Patterns for Enterprise Applications

Repository PatternSeparate the logic that retrieves the data and maps it

to the entity model from the business logic that acts on the model(data source layer can be a database, a SharePoint list, or a Web service).

Mediates between the data source layer and the business layers of the application. 1. Queries the data source for the data, 2. maps the data from the data source to a business entity, 3. and persists changes in the business entity to the data

source. Separates the business logic from the interactions with

the underlying data source or Web service.

Page 12: Design Patterns for Enterprise Applications

Using Repository Pattern:Maximize the amount of code that can be tested

with automation (support unit testing).Access the data source from many locations,

centrally managed, consistent access rules and logic.

Implement and centralize a caching strategy.Improve the code's maintainability and

readability.Use business entities that are strongly typed so

that you can identify problems at compile time instead of at run time.

Associate a behavior with the related data (business rules).

Page 13: Design Patterns for Enterprise Applications

Interfacepublic interface IRepository<T> { void Insert(T entity);

void Delete(T entity); IQueryable<T> SearchFor(Expression<Func<T, bool>> predicate);

IQueryable<T> GetAll(); T GetById(int id); }

• Implementationpublic class Repository<T> : IRepository<T> where T : class, IEntity { protected Table<T> DataTable; public Repository(DataContext dataContext) { DataTable = dataContext.GetTable<T>(); } public void Insert(T entity) { DataTable.InsertOnSubmit(entity); }...

Repository Pattern

Page 14: Design Patterns for Enterprise Applications

public interface ICustomerRepository{

Customer GetCustomerById(string id);IEnumerable<Customer> FindByName(string name);void AddCustomer(Customer customer);

}

Interactions of the repository

Page 15: Design Patterns for Enterprise Applications

Inversion of Control (IoC)The object coupling is bound at run time by

an assembler object and is typically not known at compile time using static analysis.

The binding is achieved by using: Dependency Injection (DI) Service Locator

Page 16: Design Patterns for Enterprise Applications

As a design guideline serves the following purposes:There is a decoupling of the execution of a certain

task from implementation.Every module can focus on what it is designed for.Modules make no assumptions about what other

systems do but rely on their contracts.Replacing modules has no side effect on other

modules.Associated with dependency injection which is the

main method to implement inversion of control.Sometimes referred as the "Hollywood Principle:

Don't call us, we'll call you“.

Page 17: Design Patterns for Enterprise Applications

Dependency Injection (DI)There are several styles to implement DI

Constructor Injection Setter Injection Interface Injection

Page 18: Design Patterns for Enterprise Applications

Dependency Injection (example)

Implementation public static T Get<T>() where T : class { string implName = Program.Settings[typeof(T).Name].ToString(); object concrete = Activator.CreateInstance(Type.GetType(implName)); return (T)concrete; }The code used to call the method:

IPlugin plugin = PluginFactory.Get<IPlugin>();plugin.OutputMessage("hello, world!");

The definition in the config file: <setting name="IPlugin" serializeAs="String">

<value>GrinGod.Dependency.PluginTwo.PluginTwo,GrinGod.Dependency.PluginTwo</value> </setting>

Page 19: Design Patterns for Enterprise Applications

Referenceshttp://www.codeproject.com/Articles/615139/An-Absolute-Beginners-Tutorial-on-Dependency-Inverhttp://msdn.microsoft.com/en-us/library/ff649690.aspxhttp://en.wikipedia.org/wiki/Inversion_of_controlhttp://en.wikipedia.org/wiki/Dependency_Injectionhttp://en.wikipedia.org/wiki/Separation_of_concernshttp://msdn.microsoft.com/en-us/magazine/dd882510.aspxhttp://jeffreypalermo.com/blog/the-onion-architecture-part-1/http://www.codeproject.com/Articles/37155/Implementing-Repository-Pattern-With-Entity-Framewhttp://silk.codeplex.com/http://sharparchitecture.net/