Blog Archives
Factory Pattern
Introduction
In the previous post I described using the Repository pattern to encapsulate set of Entities. The next step is creation an class which will be responsible for creating those repositories. It will be an implementation of Factory pattern ( simplified version of Factory Method pattern).
Problem definition
The Factory Design Pattern is probably the most used design pattern in modern programming languages like Java and C#. Its aim is to create objects without exposing the instantiation logic to the client. It also refers to the newly created object through a common interface. Another important factor is fact that we usually implement Factories using also Singleton pattern.
A singleton is a class which only allows a single instance of itself to be created, and usually gives simple access to that instance. In this post I’ll present also thread-safe implementation of this pattern.
Solution
Let me remind a generic implementation of Repository pattern which I presented in the previous post.
interface IRepository<T> where T : class
{
IEnumerable<T> GetAll();
IEnumerable<T> GetByQuery(Expression<Func<T, bool>> where);
T GetByID(int ID)
void Delete(T entity);
void Add(T entity);
}
The factory we want to create has to fulfil several requierments:
- It must contain generic function creating repositories
- The repositories has to be refereed through IRepository<T> interface
- It must be singleton
- It must be thread-safe
First of all I’ll implement the Factory satisfying two first conditions – simple class with one function for creating Repositories.
public class RepositoryFactory
{
public IRepository<T> GetRepositoryInstance<T, TRepository>()
where TRepository : IRepository<T>, new() where T : System.Data.Objects.DataClasses.EntityObject
{
return new TRepository();
}
}
As You can see it is rather simple. The function creating classes is an generic function which takes two types – the first one is a type of Entity which repository we are going to create, and the second one is a type of Repository we are going to create. As You can see, despite the fact that we create objects of concrete repository the function is returning IRepository<T>. This implementation is rather simple but contains one big drawback – someone can create many objects of Factory class what is absolutely not necessary. So let’s make our Factory a singleton.
public sealed class RepositoryFactory
{
private static RepositoryFactory _instance;
public static RepositoryFactory Instance
{
get { return _instance ?? (_instance = new RepositoryFactory()); }
}
private RepositoryFactory()
{
}
public IRepository<T> GetRepositoryInstance<T, TRepository>()
where TRepository : IRepository<T>, new() where T : System.Data.Objects.DataClasses.EntityObject
{
return new TRepository();
}
}
The above solution presents one of the most popular Singleton Design Pattern implementation. The constructor of class is private so we cannot just create an Factory object. The access to object is get by an Instance property ( which, BTW, contain also so Lazy Loading features – the object is created only when it is need, not during program start ) which can return only existing object of this class. Only this instance is able to invoke a function which creates repositories.
As hinted at before, the above is not thread-safe. Two different threads could both have evaluated the test if (instance==null) and found it to be true, then both create instances, which violates the singleton pattern. Note that in fact the instance may already have been created before the expression is evaluated, but the memory model doesn’t guarantee that the new value of instance will be seen by other threads unless suitablememory barriers have been passed. Below solution presents simple thread-safe mechanism base on lock keyword.
public sealed class RepositoryFactory
{
private static RepositoryFactory _instance;
private static readonly object _padlock = new object();
public static RepositoryFactory Instance
{
get
{
lock (_padlock)
{
return _instance ?? (_instance = new RepositoryFactory());
}
}
}
private RepositoryFactory()
{
}
public IRepository<T> GetRepositoryInstance<T, TRepository>()
where TRepository : IRepository<T>, new() where T : System.Data.Objects.DataClasses.EntityObject
{
return new TRepository();
}
}
Conclusion.
This post presents usage an implementation of next, two popular Design Patterns – the Factory Pattern used for creation of objects from same family ( e.g. implementing same Interface) and Singleton Pattern which ensures that there will be only one object of given class in a application -the presented solution is also thread-safe what is very important in case of growing popularity of parallel programming methods.
Entity Framework: many-to-many relationships
Introduction
Before I start with design patterns and all information about them I have to give You some information about one feature of Entity Framework which will be very useful in our future reflections. The topic of this post is many-to-many relationship handling in Entity Framework.
Problem definition
A many-to-many relationship is a type of cardinality that refers to the relationship between two entities A and B in which A may contain a parent row for which there are many children in B and vice versa. For instance, think of A as Authors, and B as Books. An Author can write several Books, and a Book can be written by several Authors. Because most database management systems only support one-to-many relationships, it is necessary to implement such relationships physically via a third junction table, say, AB with two one-to-many relationships A -> AB and B -> AB. In this case the logical primary key for AB is formed from the two foreign keys. Thus, assuming that EF tries to map all tables on the classes directly we should get another, additional class which is created for the junction table and it contains only two navigational properties ( so called Associative Entity).
Solution
Entity framework handles tables participating in many-to-many relationship in a nice way. If the junction table only consists of the foreign keys and no other columns, then that table is omitted by EF and the two sides get a navigational property exposing a collection of the other side. If the junction table contains other fields as well (e.g. the table has its own primary key column), then that junction table is included in the model with many-to-one relationships with both the participating tables.
Please consider following example presenting many-to-many relationship between Books and Authors
The generated Entity Model will look something like:
Thanks to such a way of mapping objects by Entity Framework we can easily manipulate and query data. Bellow I will present several examples of querying against this data.
Example Code
Finding an authors collection for book of given title.
Books searchedBook = context.Books.First(n => n.BookDescriptions.Title == searchedTitle); IEnumerable<Authors> authorsCollection = searchedBook.BookDescriptions.Authors;
Finding a titles collection for given author
Authors searchedAuthor = context.Authors.First(n => n.Surname == searchedSurname); IEnumerable<string> titleCollection = searchedAuthor.BookDescriptions.Select(n => n.Title);
Finding a book list for given author
Authors searchedAuthor = context.Authors.First(n => n.Surname == searchedSurname); IEnumerable<Books> bookList = searchedAuthor.BookDescriptions.Select(n => n.Books.First());
Limitations
Unfortunately ( or maybe fortunately) EF behaves in above present way only in case of junction tables which contains only two foreign keys. But, of course, it is not a drawback – if You had had to insert additional columns into junction table it represents not only simple association between two entities but rather an association class.
Conclusion
I hope You like this short introduction to handling many-to-many relationships in Entity Framework 4.0. In the beginning I’ve defined a problem which could have happened during using O/R mapping and than I’ve explained how EF handles such a situation. Next, some example source code has been presented. At the end I also have presented some limitations of EF in this area.

