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

2. DesignPatterns • “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.

3. DesignPatterns • Types 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.

4. Client-Server

5. Client-Server

6. Separation of concerns (SoC) • Good design of the architecture • Separate 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.

7. AspectOrientedProgramming (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.

8. AspectOrientedProgramming (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.

9. SOA • Asoftware 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 technology • A service is a self-contained unit of functionality, such as retrieving an online bank statement.

10. SOA

11. RepositoryPattern • Separate 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. • Queries the data source for the data, • maps the data from the data source to a business entity, • 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.

12. 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).

13. RepositoryPattern • Interface publicinterface IRepository<T> { voidInsert(T entity); voidDelete(T entity); IQueryable<T> SearchFor(Expression<Func<T, bool>> predicate); IQueryable<T> GetAll(); T GetById(int id); } • Implementation publicclassRepository<T> : IRepository<T> where T : class, IEntity { protectedTable<T> DataTable; publicRepository(DataContextdataContext) { DataTable= dataContext.GetTable<T>(); } publicvoidInsert(T entity) { DataTable.InsertOnSubmit(entity); } . . .

14. Interactions of therepository • public interface ICustomerRepository{ CustomerGetCustomerById(string id);IEnumerable<Customer> FindByName(stringname);voidAddCustomer(Customercustomer);}

15. 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) • ServiceLocator

16. 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“.

17. Dependency Injection (DI) • There are several styles to implement DI • Constructor Injection • Setter Injection • Interface Injection

18. Dependency Injection (example) • Implementation publicstatic T Get<T>() where T : class {stringimplName = Program.Settings[typeof(T).Name].ToString();objectconcrete = Activator.CreateInstance(Type.GetType(implName));return(T)concrete; } • The code used to call the method: IPluginplugin = PluginFactory.Get<IPlugin>(); plugin.OutputMessage("hello, world!"); • Thedefinition in theconfig file:<settingname="IPlugin" serializeAs="String"> <value>GrinGod.Dependency.PluginTwo.PluginTwo,GrinGod.Dependency.PluginTwo</value> </setting>

19. References http://www.codeproject.com/Articles/615139/An-Absolute-Beginners-Tutorial-on-Dependency-Inver http://msdn.microsoft.com/en-us/library/ff649690.aspx http://en.wikipedia.org/wiki/Inversion_of_control http://en.wikipedia.org/wiki/Dependency_Injection http://en.wikipedia.org/wiki/Separation_of_concerns http://msdn.microsoft.com/en-us/magazine/dd882510.aspx http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ http://www.codeproject.com/Articles/37155/Implementing-Repository-Pattern-With-Entity-Framew http://silk.codeplex.com/ http://sharparchitecture.net/