Monthly Archives: April 2012

Data Access Layer – Get Art Collection Method

The following code snippet is the GetArtCollectionDataMethod(), from the ArtWorldCollectionArtPiece class, we discussed in the last post. This method demonstrates a practical application, of the separation of concerns concept, within a layered application architecture.

Within this one small method, we are utilizing all of the architectural layers;

    • This method performs a query against the entity data model, in the The Data Model Layer, which gives the application separation and independence from the data source.
    • The code in this method creates new instances of objects from the World of Art Domain, which are populated, or hydrated, with data obtained through the entity data model.

Do you remember how the entity data model maintains the one-to-many relationship, between the artist and their works of art? Even though the LINQ query is running against the WorksOfArt class in the object model, we not only have access to each work of art object, we also have access to the associated artist object as well.

Finally, this methods generates a generic list of objects from the World of Art domain. This list has a public access modifier, so it can be consumed by many different software clients. Each client can simply create a new instance of the ArtWorldCollectionArtPiece class, and all of the information needed, is in an enumerable generic list, for easy consumption.

Let’s wrap up our discussion of layered architecture and separation of concerns, by taking a look at the World of Art web app in the Visual Studio solution explorer;

Layered Architecture

Solution with layered architecture

The four architectural layers are highlighted in the illustration above;

  • The ArtWorldObjects class library is where the World of Art domain is abstracted into classes
  • The DataAccess folder in the WorldOfArtWebApp project contains the abstract interface for serving data to various clients
  • The DataModels folder contains the object relationship model, based on the Entity Framework
  • The Views folder contains the elements of the user interface

Data Access Layer – Reusing the Abstract Interface

Lets take some time to examine the re-usability of the abstract interface we implemented in the previous post. This time we will implement the IArtWorldCollection interface, to create a collection of works of art, along with artists who created them. Once again here is a code snippet of the interface;

Now, here is the second implementation of this interface, in a class I named ArtWorldCollectionArtPiece. The purpose of this class, is to create a collection of works of art, found in the World of Art domain;

This implementation is essentially the same as the ArtWorldCollectionArtist class, except for two very import elements. Notice that in this implementation, I replaced the generic object type of “T” with the art piece object from the World of Art Domain, which is defined in the ArtWorldObjects class library. This object replacement occurred in two places, one is at the beginning of the class, where the implementation of the IArtWorldCollection interface is declared. The second is in the ArtWorldCollection property, which is defined as a type of Generic List Class.

This second implementation demonstrates just how re-usable the IArtWorldCollection interface is. This high level of reuse is achieved by coding the interface based on a generic type “T”. For more information on generic types in C#, see An introduction to C# Generics and Generic Interfaces C# Programming Guide. The IArtWorldCollection interface, can be reused over and over again, to generate many different collections of objects found in the world of art domain. These are enumerable collections of objects, which can be consumed by many different kinds of software clients.

In my next post, we will examine the GetArtCollectionData() method of the ArtWorldCollectionArtPiece class in more detail, and wrap up our discussion on separation of concerns,the entity framework, and the data access layer of our application architecture.

Data Access Layer – Implementing the Abstract Interface

In this post, I will demonstrate how I implemented the abstract interface called IArtWorldCollections. Below are two code snippets illustrating the implementation;

Following is the C# source code of the IArtWorldCollections interface. The interface has the following components;

  • A read only property, called WorksOfArtContext of type object context. The entity data model is an Object Context Class
  • A read only property, called ArtWorldCollection of type generic list. The Generic List Class Represents a strongly typed list of objects that can be accessed by index. It Provides methods to search, sort, and manipulate lists.
  • A read only property, called ExceptionMessage of type string. This property will store the message text, generated by any exceptions, thrown by any operations, performed in the methods of the class implementing the interface.
  • The final component is a method, called GetArtCollectionData, which accepts no parameters and returns no value. The purpose of this method, is to populate objects in the World Of Art Domain, with data from the World of Art entity data model. Then add each object, to the generic list property, called ArtWorldCollection.

Now lets implement this interface in an actual C# class. Following is the C# source code, for a class I added to the data access layer. The class is called ArtWorldCollectionArtist, and as you can see, it implements the IArtWorldCollection interface, replacing the generic type T, with an object of type Artist, from the World of Art Domain. We replaced the generic object type of T, with the object type of Artist, because the purpose of this implementation is to generate a list of Artist objects, populated with data through the entity data model.

The three properties of the IArtWorldCollection interface are implemented with the following protected members of the class;

  • m_context, of type WorldOfArtContext, from the object context class of the WorldOfArt entity data model
  • m_artistList, of type Generic List, object type of Artist replaces the generic T type
  • m_exceptionMessage, of type string

The constructor method of the ArtWorldCollectionArtist class, initializes the protected members based on their object types. The constructor method also calls the GetArtCollectionData() method. In this method I use the Language-Integrated Query(LINQ) syntax available in C#, to perform a query against the World Of Art data model. We will cover LINQ in more detail in a future post. I employ a ForEach loop, to load the results of the query into the Artist List Collection. Notice how the query is not against a SQL Server databse table, instead the query is against the Artist property of the object context, in the World of Art Data Model. Therefore, I can create a new instance of the Artist object from each Artist in the result set of the query. I can populate the properties of the Artist object, with data from the properties of the Artist class in the data model.

Finally, with the implementation of the IArtWorldCollection interface, we have achieved the separation of concerns we’ve been striving for. Notice how the ArtWorldCollectionArtist class has no concern for the source of the artist data. There is no code for opening and closing a connection to the database server. No need for hard coded SQL commands like “SELECT FirstName, LastName, BirthDay, City, Country, TypeOfArtist FROM aspnet_Artist” which can be severely impacted by changes to the database tables. The coding task is simplified by the entity data model, because now I’m coding against classes and properties, instead of hard coding table and column names. The hard tasks, of connecting to the database and accessing the tables of the database, have been abstracted into the entity data model. Even if the source of data changes from a Microsoft SQL Server database, to an ORACLE database, or even a data service, the ArtWorldCollectionArtist class would not be impacted by any of these changes.

One last comment on implementing a generic interface for data access, through the entity data model. The payoff for using this approach will continue to increase, as we further implement the interface, to access data and populate other elements in the World of Art domain; such as the works of art created by the artist. More on this in my next post.

Separation of Concerns – Data Access Layer

Now that the World of Art database has been abstracted, as an entity data model, we can focus on adding the data access layer to our architecture. This layer will act as an interface to the entity data model. The data access layer will create distance and independence from the data source, for the user interface layer, the business logic layer and the services layer.

The first thing I want to do in the data access layer, is create an abstract interface. The following code snippet illustrates this. As you can see, this is a generic interface. I’m using the System.Collections.Generic class, to declare this as a public interface called IArtWorldCollection, which implements a generic object type signified by “T”. The single purpose of this interface, is to create a generic list or collection of objects, from the World of Art Domain. We will reveal the details on how this is done, when we actually implement this Interface.

The Data Model Layer

As discussed in the last post, we are going to apply a layered architectural structure, to the World of Art web app. The first layer we are going to develop, will be called the Data Model Layer. The purpose of this layer is to achieve a separation of concerns. To create distance and independence, between code supporting the application’s user interface, and code supporting access to the data source.

We will begin by adding an object model to the application. This object model is based on the World Of Art Relational Database, developed in a prior iteration. See Generating Data Model Based on Relational Database, for step by step instructions on generating the data model. As mentioned in previous posts, our data model layer is based on the Microsoft ADO.NET Entity Framework.

Now that the data model is generated, I’m going to display another illustration of the World of Art database diagram, which the data model is bases on. This diagram is more detailed, and shows the properties of each column of the two tables, currently in the database. Also, remember the “one-to-many” relationship between an artist and their works of art. An artist can create one or more works of art. This relationship is illustrated by the key and infinity symbols in the diagram. Please keep this diagram in mind, when we examine the data model diagram, based on this database.

Database Diagram for Data Model

World of Art Database Diagram

The next diagram illustrates the data model, which is based on the World of Art database. I used the Entity Data Model Wizard in Visual Studio 2010, to generate the data model. The data model has two classes, based on the two tables in the World of Art database. The Artist table and the Works of Art table, have been abstracted into two separate classes. The columns of the tables are now represented by the properties of each class. Also, notice how the one-to-many relationship between an artist and their works of art is maintained.

Data Model based on World of Art Database

Data Model based on World of Art database

The Entity Data Model Wizard in Visual Studio 2010, not only generates the entity data model diagram illustrated above, it also generates an entire C# code file, which the diagram is based on. The following image is a class diagram I generated in Visual Studio 2010. It’s based on the WorldOfArt.Designer.cs file which was generated by the Entity Data Model Wizard. As you can see, the wizard actually generated three classes. The one in the middle is the WorldOfArtContext class, it inherits the System.Data.Objects.ObjectContext class. The other two classes are based on the two tables in the World of Art database, and inherit the System.Data.Objects.DataClasses.EntityObject class. Like any typical C# class, they have private members and public properties, along with a wide range of partial methods and event handlers, for updating the tables.

WorldOfArt.Designer.cs Data Model Class Diagram

Class Diagram Based on World of Art Data Model

Finally, lets take a look at the World Of Art solution in Visual Studio, with the newly added Data Model layer. The highlighted folder, in the illustration below, represents the Data Model Layer in the World of Art project solution. The folder contains two files;

  • The WorldOfArt.edmx file, is the data model diagram. It can be viewed and modified, in the Entity Data Model Designer, in Visual Studio.
  • The WorldOfArtDesigner.cs file, is the C# source code of the Entity Data Model.
Data Model Layer in Solution Explorer

Data Model Layer in the World of Art Project Solution

In my next post, I’ll discuss the benefits derived from building a Data Model Architectural Layer, and an Entity Data Model.

Layered Architecture & Separation of Concerns

Now that I have dealt with my philosophical and project management issues, we can get back to improving the design of the World of Art web app. If you recall my previous post on Improving the Design, I identified several objectives for improving the application design;

  • Eliminate the tight coupling of the user interface and data access, by extracting database connectivity and data access, into a separate architectural layer of the application.
  • Design and build an abstracted view of the data access domain.
  • Develop an interface to the data access domain.

A tremendous amount of progress towards meeting these objectives, can be gained by implementing the Microsoft ADO.NET Entity Framework. The Entity Framework provides a means for achieving our design objects. However, the Entity Framework provides even greater benefits;

  • Enables me to program against a conceptual application model instead of programming directly against a relational database schema.
  • Decreases the amount of code and maintenance required for data-oriented applications.
  • Provides freedom to focus more on the problem/business domain issues, and much less on database access and query issues.

Now with all that said, the ADO.NET Entity Framework is no the complete solution for improving the design of our application. The core purpose of our design objectives is to establish a separation of concerns, by creating distance between dissimilar aspects of our code.

Separation of Concerns

Kyle Baley, Donald Belcham and James Kovacs, wrote an excellent series in MSDN Magazine called Extreme ASP.NET Makeover. Part six of this series deals with the subject of separation of concerns.

Another design improvement objective, is to introduce a layered architecture to our design. The traditional layered architecture of a software application, utilizes three basic layers for separating coding concerns;

  • User Interface
  • Business Logic
  • Data Access

Layered Architecture

Applying a layered architectural design to an app is always good practice, because it simplifies each component of the app, and improves maintainability in a way that lends itself very nicely to evolutionary improvements, as opposed to total re-writes. However, applying a layered design to large, complex, enterprise level applications, can introduce other levels of tight coupling which should be avoided.

Hendry Luk wrote a very good piece on this subject. See Software Development Fundamentals, Part 2: Layered Architecture

Jeffrey Palermo also tackles this issue in his series on The Onion Architecture.

Please keep in mind, the concepts covered by Hendry Luk and Jeffrey Palermo, are intended for large enterprise level apps, with complex behaviors and long running life cycles. However, it is good to study and understand these concepts. As developers, it is our responsibility to determine the best practical application of these concepts, based on a desire to satisfy our customer’s needs and our project requirements.

In my next post, we will introduce a Data Model Layer to our application. In this layer, we will utilize the ADO.NET Entity Framework, to create an object model over the World of Art Relation Database.

Source Code Management

Before moving forward with the next iteration of development, I realized there was some administrative work which needed to be taken care of first. I need to bring source code management  technology into the project. With an agile approach to development, it doesn’t take long for a lot of source code and documentation to start piling up. In particular, it’s the number of source code files, which can proliferate and cause confusion. In my opinion, some form of source code management and version control, is absolutely necessary in every software project, regardless of scale, or how many people are working on the project.

There are several aspects to source code management, which should be considered, when selecting tools and technologies for this area of project management. Here are a few things to consider;

  • Version control, at the source code file level, and application level
  • A safe and secure repository for files and documents
  • Controlled access to the repository
  • Ability to check out, and check in files, in the repository
  • Historical log of who made changes, and the nature of the changes
  • Should be easy to use,so as not to distract from core development activities

There are several source code management/repository tools which are readily available. The most popular are;

All three are open source projects, which can be downloaded free of any license fees.

Along with a source code repository and version control system, you also need to find a safe and secure place to host the repository. For this purpose, I chose Google Code. This is a free and secure, project hosting service from Google. Along with hosting the source code repository, Google code provides a number of tools, for documenting and managing projects. Google Code provides easy and convenient access, to the source code of The World of Art project. For review purposes, I plan to provide the readers of this blog, direct access to the source code repository. Google Code supports Subversion, Git and Mercurial.

Finally, I prefer having the luxury, of a transparent integration, between my version control system and my development environment. For this reason, I’ve selected VisualSVN. VisualSVN is a professional grade, Subversion integration plug-in, for Visual Studio. It also supports repository hosting by Google Code. By default, selecting VisualSVN, means I’m also going with Subversion, for source code management.

The following image illustrates the solution explorer, just after the initial commitment of the World of Art project to Subversion, hosted at Google Code. Notice the little green icon next to most elements in the solution. This is a visual indication that the source code file is under version control. The illustration also shows the message log provided by VisualSVN.

VisualSVN integrated in Visual Studio 2010