Currently, I have a big and ugly helper class for getting data from the (SharePoint 2010) term store. I want to refactor this into something more robust and maintainable. Is there any design pattern I should use that is "best-practice"? I was thinking about the repository pattern, but currently I only read data, so that might not be what I'm looking for?
there are 4 main patterns that are commonly used! between them mvp and repository are the most common, in you case i would belive the best option would be repository:
•The Model-View-Presenter (MVP) Pattern
•The Repository Pattern
•The Service Locator Pattern
•The Trusted Façade Pattern
The Repository Pattern
if you hit any of these points as i think you do than this is the one for you:
Context In many applications, the business logic accesses data from data stores such as databases, SharePoint lists, or Web services. Directly accessing the data can result in the following:
•Duplicated code •A higher potential for programming errors •Weak typing of the business data •Difficulty in centralizing data-related policies such as caching •An inability to easily test the business logic in isolation from external dependencies Objectives Use the Repository pattern to achieve one or more of the following objectives:
•You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing.
•You access the data source from many locations and want to apply centrally managed, consistent access rules and logic.
•You want to implement and centralize a caching strategy for the data source. •You want to improve the code's maintainability and readability by separating business logic from data or service access logic.
•You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
•You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity.
•You want to apply a domain model to simplify complex business logic.
more on the patterns can be found here: