1 / 19

Design Patterns for Enterprise Applications

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 .”

ham
Télécharger la présentation

Design Patterns for Enterprise Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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/

More Related