Building High Quality Solutions with Design Patterns & Application Foundations for SharePoint 2010
•Transferir como PPTX, PDF•
1 gostou•2,450 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Building High Quality Solutions with Design Patterns & Application Foundations for SharePoint 2010
Semelhante a Building High Quality Solutions with Design Patterns & Application Foundations for SharePoint 2010 (20)
Último
Último (20)
Building High Quality Solutions with Design Patterns & Application Foundations for SharePoint 2010
- 1. Th26 - Building High Quality Solutions with Design Patterns & Application Foundations for SharePoint 2010 Christoffer von Sabsay christoffer.von.sabsay@sogeti.se
- 2. About Me Christoffer von Sabsay SharePoint Architect Sogeti Sweden MCPD, MCT
- 3. Agenda • Design Patterns – what, why and when? • Repository Pattern • Model-View-Presenter Pattern • Service Locator Pattern • Application Foundations for SharePoint 2010
- 4. SharePoint vs .NET development • SharePoint is just a .NET application, right? • So are there really any differences between SharePoint and plain .NET development?
- 5. Design Patterns • What is it? • Why should we use it? • When should we use it?
- 6. Repository Pattern Business Entity Repository Persist Client Data Business Source Logic Retrieve Entity – Data Mapping Business Entity
- 7. Model-View-Presenter Pattern View IView Presenter Model
- 8. Service Locator Pattern Service A Class Service Locator Service B
- 9. Benefits after applying these patterns • Repository Pattern – Central point of access to data – can modify storage without too much impact on the rest of the code – Strongly typed access to our data • Model-View-Presenter – Presentation logic separated from UI – Possible to reuse presentation logic for different Uis • Service Locator – Decoupled dependency between presenter and repository – Presenter testable in isolation – Service Locator takes care of creating and managing the lifetime of the service/repository.
- 10. Application Foundations for SP2010 • SharePoint Service Locator • Logger • Configuration Settings Manager
- 11. SharePoint Service Locator • Lightweight Service Locator • Implements the IServiceLocator interface (Microsoft.Practices.ServiceLocation) • Mappings can be stored at the farm or site collection level • Default type mappings – Logging – Configuration Management
- 12. Other options for Service Location • Unity • Spring.NET • StructureMap • Other frameworks
- 13. Logger • Utility class for logging • Two methods – TraceToDeveloper (ULS) – LogToOperations (Event Log + ULS) • Implements the ILogger interface, easy to replace by custom implementation
- 14. Configuration Settings Manager • Utility class for storing and retrieving configuration settings • Settings can be stored in the property bag at different levels – SPFarm, SPWebApplication, SPSite and SPWeb • Also possible to store settings in a SPList
- 15. Summary • Learn about the different design patterns and when to use them • Use Application Foundations for common tasks such as configuration and logging
- 16. Resources Developing Applications for SharePoint 2010 http://msdn.microsoft.com/en-us/library/ff770300.aspx Developing Applications for SharePoint 2007 http://msdn.microsoft.com/en-us/library/ff800762.aspx Application Foundations for SharePoint 2010 http://msdn.microsoft.com/en-us/library/ff798371.aspx
- 17. Questions?
- 18. Keep in touch! E-mail: christoffer.von.sabsay@sogeti.se Blog: http://christoffervonsabsay.wordpress.com Twitter: sabsay
Notas do Editor
- First we’re going to talk a little bit about design patterns for development and how these patterns can help you write solutions that works as expected, are easy to test, easy to maintain and to extend with additional functionality.Repository, MVP and Service Locator Pattern. Some of you might be familar with these patterns – the patterns themselves are general patterns for system development, so it’s not something that’s specific for SharePoint. But we’re going to talk about how these can be applied specifically in SharePoint development projects.We’re also going to talk about the Application Foundations library from MS P&P, which is a useful library for dealing with common tasks such as logging, configuration and service location.00:05
- 00:05Let’s talk a little bit about the differeneces between developing applictions on SharePoint and ordinary .NET development.SharePoint, as you know, is an application and collaboration platform build on top of the .NET framework. There are a few unmanaged components left unfortunatley, but all APIs that you will work with are .NET.So it’s working thinking a little bit about if there really are any differences between developing solutions on .NET and on SharePoint, except that of course you need to know a LOT more about the huge building blocks of functionality and services that SharePoint provides.The answer is yes and no.SharePoint is a platform with a huge amount of functionality and features that you can use to solve a wide range of business challenges. And since the 2007 version that SharePoint really evolved from a product to a platform. You can build very powerful applications with no or very little development. The main challenge is to try to create solutions that solves the customers challenges, using as much of the oob functionality as possible. Of course we should try to use OOB or lightweight customization as much as possible.However, in most real world cases, especially when building large enterprise applications with specific requirements and integrations against legacy systems, 100% out of the box is just not going to work. You will in many cases need to develop custom code. This can renge from a few simple web parts and event receivers, to very customized solutions.When you decide to build a solution with a significant custom development, SharePoint development becomes more and more similar to .NET development. There is really no differences – you will need to think about how to write an application that just not works as expected, but is easy to test, troubleshoot, maintain and develop further.And that’s where design patterns come into place.00:10
- 00:10So what are design patterns?When developing applications with some degree of complexity, you will run into a several challenges regarding how you should design your application and write your code.There are a number of principles that will help you adress these challenges:-Design patterns are proven patterns that help you write code based on these principles. The patterns should be applied should use it to solve specific issues / challenge. We shouldn’t always use them – if you have very little custom code. Simple event receiever, layout page or web part – no need for patterns. Complex solutions – there are many benefits.So, what I want to show you today, is a number of patterns and examples on how these can be applied specifically to SharePoint and ASP.NET development scenario.00:15
- 00:15Repository pattern should be used when you have a significant amount of custom code that need to access data from a data source, i.e. a SharePoint list, data base, or some other data source. In our example, we accessed the data directly form our web part to the data source, which in this case is a SharePoint list.If you choose to access your data directly from your client business logic, i.e. a web part, there are a few issues:In most cases, you will work with weak typing of the business data.Duplicated codeDifficult to handle policies such as a unified caching, logging.Won’t be able to test your components that access the data in isolation, because you have a direct dependency on the data sourceDifficult to change the underlying storage mechanism of neededTo solve this, you create a repository, which is a layer between the business logic and the data source, where you centralize all data access.Repository will have methods for retrieving and storing data as strongly typed objectsIndependent of storage mechanismCentral part of this is a mapping between data and entities – i.e. SPListItem and business object.00:20
- 00:20Te idea with the MVP pattern is to separate your UI, which in our case would be the html, buttons and other UI elements in our web part, from the presentation logic. The presentation logic is basically what controls the flow in our application. I.e. that when the user has requsted to show the hotels, you get the criteria that the user has entered, query the repository and return the hotels if found, otherwise you show a message which says that no hotels are found.The MVP pattern itself is just a pattern, not a technology, so you can actually implement this pattern with ordinary web forms, which we use for SharePoint development.In the MVP pattern we separate the UI, which is called the view - from the presentation logic, which is called the Presenter. The view in our case would be our web part, so to implement this pattern we need to separate the presentation logic into a presenter. We create an interface that the view implements, that’s used to pass on and get data to and from the view. This view is passed on to the presenter in some way, i.e. through the constructor. Since the presenter only knows about the interface Iview, it’s totally independent of the exact implementation of the view.The model would be our underlying business layer, data storage, services, and so on.Benefits:We can unit test the presenter and mock the viewWe have the presentation logic separated, which makes it easier to codeWe can reuse the presentation logic in several different view (i.e. Web part, layouts page, mobile page).00:25
- 00:25Allright, so now we have the data access code separated in a repository. We have separated the presentation logic from the UI. So we’re pretty close to being able to create an unit for test our presentation logic. However, we still have a direct dependency from the presenter to the repository, which makes this impossible.And that’s where the service locator pattern comes into play. What we want to do is to remove the direct dependency to the repository, and we can use a service locator to do that.So we make sure that all services we are dependent on has an interface, and then we register this interface and the concrete implementatino in the service locator.The class (our presenter) will then ask the service locator for the instance of a specific interface. The service locator is responsible for creating instance of the service and managing the lifetime of the object. This is configurable. 00:35
- 00:35Allright. So we have talked about a few design patterns that can be useful when developing applications.Let’s move on the application foundations library for sharePoint 2010. This is a small but useful library created by the Microsoft Patterns & Practices team, that’s a part of the ”Developing Applications for SharePoint 2010” guidance, which contains best practices, sample solutions and this library.Simple service locator implementation that uses the SharePoint property bags to store mapping between interfaces and implementations.Helper classes to log entires to the ULS and event log.Configuration Settings manager that helps you retrieve and store configuration settings for your applications.
- The SharePointService Locator is a quite simple implementation of a service locator. It’s easy to use and get started with, but there are other options.If you choose a fully featured Dependency Injection framework such as Unity or Spring.NET, you will have a lot mor options regarding how you can configure your classes.You can use XML or code to configure how your services are constructed, send in other classes in the constructor or setter properties. You can also add policies for logging and error handling (in Unity this is called interception), which adds this functionality automatically to all calls that goes through the objects you resolve through the service locator.For enterprise applications, this is probably a better choice than the service locator. 00:35
- 0.40
- 00:40