Building a Module for Sitefinity (part 5) : Module structure

Building a Module for Sitefinity (part 5) : Module structure

May 15, 2007 0 Comments

The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.

The Contacts pluggable module will be made of two assemblies : Sample.Contacts and Sample.Contacts.Data

The business logic and UI will be implemented in Sample.Contacts module, while the data access we’ll be done through the Sample.Contacts.Data assembly. Take a look at the following diagram to see the big picture :

Contacts module diagram

Sample.Contacts assembly

There are five main parts of this assembly :

  • Web controls - Admin web controls that will provide a way for authorized users to work with contacts and Public controls that will display the contacts on the pages.
  • Contacts Manager - Web controls will work exclusively with Contacts Manager when manipulating data.
  • Contacts Provider - Contacts manager will call the methods inside of a provider class. Since there can be more than one provider (Sql and XML for example) the Contacts Provider is an abstract class that the actual provider classes need to derive from. In addition to this, the Contacts Provider class will be used to retrieve various settings from web.config used by the module (like paths to external templates and such).
  • Both, Contacts Manager and Contacts Provider classes will get the needed settings from web.config by using Configuration classes.
  • Finally, we have Resources where all the messages and labels will be stored in case we decide to localize our module at later stage.

Sample.Contacts.Data assembly

There are four main parts of this assembly :

  • Contact (dbclass) - Nolics class that will define the database object for storing contacts and it’s Contact partial class that we’ll use to add some additional functionality
  • Department (dbclass) - Nolics class that will define the database object for storing departments and it’s Department partial class that we’ll use to add some additional functionality
  • Default Provider - This class derives from Contacts Provider abstract class and will actually implement all the data manipulation methods (such as inserting a new job, deleting a department etc.)
  • Resources - here mostly to hold error and exception messages in case we decide to localize the application at later stage

In the next post I’ll provide the link for the latest version of the project and describe briefly what’s been done. If you have questions or suggestions, don’t hesitate to leave the comment :)


The Progress Team

View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Comments are disabled in preview mode.
Latest Stories in
Your Inbox
More From Progress
The New Mobile Development Landscape
Download Whitepaper
IDC Spotlight Sitefinity Thumbnail
Choosing the Right Digital Experience Platform to Improve Business Outcomes
Download Whitepaper
The Fastest Way to Build Mobile Apps With Cloud Data
Watch Webinar