Data Layer

Any application using data benefits from having a separate data layer. This enables the administrator to select which data source to use. It also makes your application have an advantage, making it easier to sell.

Besides from the advantages for the end-users, it’s also best practices to separate the data layer from your presentation and business logic layer.

To provide the data layer to the application a Data project was added. The layers above the data layer never accessed the real data implementations, but worked with objects which implemented certain data interfaces. This way, it was possible to define all possible data related methods in an interface and afterwards implement them in a real implementation.

A logical grouping was applied when creating the interfaces, starting from a generic IDataAccessor from which every other interface inherited from.

[csharp] using System;

namespace MediaService.Data.Accessors { public interface IDataAccessor { } / IDataAccessor / } / MediaService.Data.Accessors / [/csharp]

One of the logical sections was for example everything related to Song objects:

[csharp] using System;

using MediaService.Objects;

namespace MediaService.Data.Accessors { public interface ISongDataAccessor: IDataAccessor { Song[] GetSongs(); Song[] GetQueue(); Song[] GetMostPlayed(Int32 numberOfSongs); Song[] GetMostPopular(Int32 numberOfSongs); } / ISongDataAccessor / } / MediaService.Data.Accessors / [/csharp]

Since the other projects did not have a reference to the real data implementations, but only to the Data project, this project had to take care of loading the correct implementation. Loading the correct class in the real implementation is done by using factories. For every Accessor interface a factory exists, returning an instance of the data implementation, using the following code:

[csharp] using System; using MediaService.Data.Accessors;

namespace MediaService.Data.Factory { internal class SongFactory: Factory { internal static ISongDataAccessor Create() { return Factory.Create(Accessor.Song) as ISongDataAccessor; } / Create / } / SongFactory / } / MediaService.Data / [/csharp]

In the Data project, there was one Factory class, responsible for loading the correct assembly containing the data implementation and instantiating the correct Accessor class. This was done by using Reflection together with Configuration to retrieve the location. The location consisted out of the class name and the assembly name, separated by a comma, as for example the location for the SongDataAccessor:

[xml]

MediaService.Data.SqlServer.SongDataAccessor,MediaService.Data.SqlServer [/xml]

This location data was retrieved by configuration, after which it was separated into assembly and class parts and loaded with Reflection with the following code:

[csharp] using System; using System.Reflection;

using MediaService.Configuration; using MediaService.Data.Accessors;

using Microsoft.Practices.EnterpriseLibrary.Configuration;

namespace MediaService.Data.Factory { internal enum Accessor { Song } / Accessor /

internal class Factory { internal static IDataAccessor Create(Accessor accessorType) { DatabaseData configData = LoadConfiguration();

  if (configData == null) {
    throw new ApplicationException("Could not load configuration.");
  }

  String blockToLoad = String.Empty;
  switch (accessorType) {
    case Accessor.Song: blockToLoad = configData.SongDataAccessor; break;
  }

  if (blockToLoad == String.Empty) {
    throw new ApplicationException(String.Format(
              "Type entry not found for {0}.", accessorType.ToString()));
  }

  Int32 index = blockToLoad.IndexOf(",");
  string typeToLoad = blockToLoad.Substring(0,index);
  string assemblyToLoad = blockToLoad.Substring(typeToLoad.Length + 1,
                          blockToLoad.Length - typeToLoad.Length - 1);
  return (IDataAccessor)Assembly.Load(
                        assemblyToLoad).CreateInstance(typeToLoad);
} /* Create */

private static DatabaseData LoadConfiguration() {
 ConfigurationManager.ClearSingletonSectionCache("databaseConfiguration");
 return ConfigurationManager.GetConfiguration(
                       "databaseConfiguration") as DatabaseData;
} /* LoadConfiguration */

} / Factory / } / MediaService.Data.Factory / [/csharp]

All of the Factories were marked internal because they are just meant for internal workings of the data layer, while all Accessors remain public because they had to be accessible to implement in the real data implementation.

Besides the Accessor interfaces, the Data project also exposed one public class, named Dalc. This class contained static properties for each logical data section, returning an instantiated Accessor from the configured data source.

[csharp] using System;

using MediaService.Data.Accessors; using MediaService.Data.Factory;

namespace MediaService.Data { public class Dalc { public static ISongDataAccessor Song { get { return SongFactory.Create(); } } / Song / } / Dalc / } / MediaService.Data / [/csharp]

After this, it was possible to access data by adding a reference to the Data project, adding a real data implementation assembly to the deployed location and configuring it. For example, the following code retrieved all songs from the data source:

[csharp] using MediaService.Objects; using MediaService.Data; using MediaService.Data.Accessors;

namespace MediaService.Web { public class Media { public Song[] GetSongs() { return Dalc.Song.GetSongs(); } / GetSongs / [/csharp]

With this data layer, all details about data access are contained in the real data implementations, while nowhere else there is specific data source code. The entire application works on data objects, which implement the data interfaces, while under the hood, the correct data source is selected through the configuration file.

Search

Categories