This topic provides an overview of the services available in Sitefinity.
Services provide a way to create site-wide logic that could be used or implemented by any other part of Sitefinity. One available service is the RSS service. We will
use it as an example to explain why RSS is implemented as a service, and not as a module, control or anything else.
A service in Sitefinity takes a rather complicated logic that could be reused across many modules and controls, and is placed in one central place. The service itself is
not directly visible to the end users - rather, modules and controls use it to provide some intended functionality.
Why Implement Services?
RSS (Really Simple Syndication) is a format for syndication of items frequently extracted from a Web site (for more information on RSS, see RSS Feeds Overview). Now, let’s consider creating a translation service (there is no such
built-in service in Sitefinity). We are going to compare it to the implementation of the RSS service, and demonstrate why such functionalities are best implemented as
services.
A translation service should provide translation of any content inside Sitefinity to a supported language. Since this first requirement states "any content", the
best way to implement such functionality is by implementing a service. Our exemplary translation service will translate only words but it will serve as a good example of a
service.
Figure 1 – High Overview of Sitefinity Services (note: TranslationService is not a built-in Sitefinity service)
Let’s examine the RssService first, shown in Figure 1. RssContent is a public control which asks the RssService for a specific feed
without knowing anything about how to create a proper RSS feed. The RssService, on the other hand, knows how to create a proper RSS feed but it does not know which data
to use in order to create that RSS feed. Therefore, the RssService provides an IRssProvider interface to be implemented by any part of the application that would
like to expose its content through RSS. The IRssProvider interface is highly abstracted and simplified for the creation of RSS feeds - modules such as
Blogs, News or Events need only to implement this interface (which will mostly ask from the module to provide correct data). In this way, the RSS Service has hidden all
the logic for creating proper and valid RSS files from the content providers (modules) as well as from the content consumers (public controls). Exactly this is the desired
functionality that Sitefinity services provide.
Now, let’s see if the logic behind TranslationService is any different from the one implemented in RssService. Let’s assume we have implemented several links on the NewsView
control such as "German translation", "Spanish translation", "French translation". Since translating text from one language to another is a usable feature for the whole
application it makes sense to implement this feature as a service. For example, two weeks after implementing translation for News, we may decide to do the
same for BlogPosts. So, the NewsView control sends some text in English to the translation service and asks for the translation in Spanish. TranslationService knows how
to translate words, except that it doesn’t know foreign words (similarly to a person who doesn’t speak a foreign language, but knows how to look up a word in the
dictionary). RssService used IRssProvider implementations to get the actual data, so TranslationService will use XmlFiles representing dictionaries to actually find the
proper word. The benefit of this kind of infrastructure is that you can add a new dictionary for, let’s say, Italian without modifying any of the code. TranslationService knows
how to translate and it doesn’t really care from which language to which it is doing that.
Conclusion
As demonstrated, Services in Sitefinity provide a rather powerful way of implementing features. Whenever you have a need to abstract away some complex logic that will be used
by various parts of Sitefinity, Services can prove to be the best way to go.
See Also