Background Knowledge
This is for those who are not familiar with the concept of a
query provider. It's all about
IQueryable<T>. By implementing this interface, you promise that you have a class (a query provider) that knows how to populate you (typically a collection) based on some domain specific data store. It can be a document database, a relational database, or even XML. In the case of Raven and NHibernate, we're dealing with document and relational databases. Raven's domain specific language is HTTP and REST, while NHibernate's is an abstraction layer atop SQL. The heart of any LINQ provider is expression trees. We call them quotations in F#, and they can be a nightmare for you when you want to use an existing LINQ implementation. Shame on you fsc. The c sharp compiler, csc, is a lot more friendly and compliant about emitting expression trees.
That being said, expression trees are where the magic happens. They are merely runtime representations of our code. The compiler will convert our calls against IQueryable like Where and Select to expression trees at compile time as opposed to delegates. Then it's up to you to implement an expression tree visitor and LINQ provider that knows how to parse each kind of expression supported by your API. You can find NHibernate's here and Raven's here. You'll be working with runtime representations of the standard LINQ query operators like Select, Where, OrderBy, and GroupBy. I'd like to assume everyone knows that there is a difference between IQueryable<T> and IEnumerable<T>, but I highly doubt that. What can be confusing for some is when they call
var five = new List<int> {3, 4, 5}.Where(n => n % 5 == 0).Single();
and it works. That's
LINQ to Objects. In that instance, we're working with
IEnumerable<T>. The key thing to remember is that both IQueryable<T> and IEnumerable<T> both have a set of extension methods that target them, and depending on which one you use you'll either love or hate the results. The extensions for IEnumerable<T> work with in memory collections as opposed to LINQ providers and expression trees. The extensions for IQueryable<T> are just an abstraction layer sitting atop your LINQ provider. You implement the LINQ provider, and .NET will invoke it at the proper time passing in the proper arguments (an expression tree). All you have to do is parse the tree and emit your domain specific output. Then you send that output to whatever backend you're encapsulating, fetch the results, and send them back to the client. I won't go any further into LINQ providers, but I figured I could clear up a little smoke by providing some concrete examples. The last thing I'll add is that IQueryable<T> is always lazily executed (just like IEnumerable<T>) and inherits from IEnumerable<T>. All IEnumerable<T> means is that you can iterate (for each) over its results. Now it's not that simple because the compiler generates this hidden class and a state machine but we won't get into that and monads. What makes it lazy is that your query won't be executed until the client tries to actually iterate. This is cool because it allows us to continually make calls on our IQueryable<T> without it hitting our data store each time. Obviously we're not ready to consume any results until we start to iterate so everything is deferred up until that point. And don't worry about the compiler accidentally choosing the wrong call to Where or Select. It's smart enough to know that IQueryable<T> is more specific that IEnumerable<T> and invoke the right set of extensions.
I'd also like to conclude with a low level deep dive into LINQ.
Implementing the UoW
Let's get started shall we. First thing's first; we need a common interface to wrap the NHibernate and Raven sessions respectively.
public interface ISession : IDisposable {
IQueryable<TEntity> Query<TEntity>() where TEntity : Entity;
void Add<TEntity>(TEntity entity) where TEntity : Entity;
void Update<TEntity>(TEntity entity) where TEntity : Entity;
void Delete<TEntity>(TEntity entity) where TEntity : Entity;
void SaveChanges();
#region Future Load Methods. Can't use now because Raven forces Id's to be strings. If were not for that, we could make this generic between NHibernate and RavenDb.
// TEntity Load<TEntity, TId>(TId id) where TEntity : Entity<TId>;
// IEnumerable<TEntity> Load<TEntity, TId>(IEnumerable<TId> ids) where TEntity : Entity<TId>;
#endregion
}
As you can see, we make each session promise to give us an
IQueryable<T>. We're also enforcing our sessions to implement
Unit Of Work, hence the
SaveChanges method. The rest of the functions are
CRUD based. Lastly we need to be able to shut the session down and free up resources so we make all sessions implement
IDisposable.
Now we'll make the concrete
RavenSession and it's wrapper class
UnitOfWork
public static class UnitOfWork {
public static void Start() {
CurrentSession = new RavenSession();
}
public static ISession CurrentSession {
get { return Get.Current<ISession>(); }
private set { Set.Current(value); }
}
}
internal class RavenSession : ISession {
readonly DocumentStore _documentStore;
readonly IDocumentSession _documentSession;
internal RavenSession() {
_documentStore = new DocumentStore { Url = "http://localhost:8080" };
_documentSession = _documentStore.Initialize().OpenSession();
}
public IQueryable<TEntity> Query<TEntity>() where TEntity : Entity {
/* may need to take indexing into consideration. raven will generat temps for us, but that may not be so efficient.
* i don't even know how long the temps stick around for. Raven will try and optimize for us best it can. */
return _documentSession.Query<TEntity>();
}
public void Add<TEntity>(TEntity entity) where TEntity : Entity {
_documentSession.Store(entity);
}
public void Update<TEntity>(TEntity entity) where TEntity : Entity {
_documentSession.Store(entity);
}
public void Delete<TEntity>(TEntity entity) where TEntity : Entity {
_documentSession.Delete(entity);
}
public void SaveChanges() {
_documentSession.SaveChanges();
}
public void Dispose() {
_documentStore.Dispose();
_documentSession.Dispose();
}
#region Future Load Methods. Can't use now because Raven forces Id's to be strings. If were not for that, we could make this generic between nHibernate and RavenDb.
public TEntity Load<TEntity, TId>(TId id) where TEntity : Entity<TId> {
throw new NotImplementedException();
}
public IEnumerable<TEntity> Load<TEntity, TId>(IEnumerable<TId> ids) where TEntity : Entity<TId> {
throw new NotImplementedException();
}
#endregion
}
I hard coded the url for now, but obviously I'd want it to be read from configuration somewhere.
Next I need a class to store the current session. I took an idea from a buddy of mine and made it
strongly typed and
reusable. It's just a wrapper around
HttpContext that falls back to an in memory
dictionary for
unit testing purposes.
public static class Ensure {
public static void That(bool condition) {
if(!condition)
throw new Exception("an expected condition was not met.");
}
public static void That<TType>(bool condition, string message) where TType : Exception {
if(!condition)
throw (TType)Activator.CreateInstance(typeof (TType), message);
}
}
public static class Get {
public static T Current<T>() where T : class {
var context = HttpContext.Current;
var key = typeof(T).FullName;
var value = context == null ? (T)Set.InMemoryValuesForUnitTesting[key] : (T)context.Items[key];
Ensure.That(value != null);
return value;
}
}
public static class Set {
internal static Dictionary<string, object> InMemoryValuesForUnitTesting = new Dictionary<string, object>();
public static void Current<T>(T value) {
var context = HttpContext.Current;
var key = typeof(T).FullName;
if (context == null)
InMemoryValuesForUnitTesting[key] = value;
else
context.Items[key] = value;
}
}
Implementing Core Domain Objects
It's nice to have a base structure in place from which our domain objects can derive. More specifically a base
entity and
repository class. The base repository is strongly typed and knows how to persist a specific type of entity. I created a
Raven specific repository because all ids in
Raven are strings (or so I thought. Raven actually supports POID generators just like
NHibernate). That's just the default implementation. It was implemented that way so the ids could be
RESTful and
human readable. Who wants to see a
GUID on the
query string? Not I...
public class Entity {}
public class Entity<TId> : Entity {
public TId Id { get; set; }
}
public class BaseRepository<T, TId> : IRepository<T, TId> where T : Entity<TId> {
public void Add(T entity) {
UnitOfWork.CurrentSession.Add(entity);
}
public IQueryable<T> All() {
return UnitOfWork.CurrentSession.Query<T>();
}
public virtual T Get(TId id) {
return All().Where(e => e.Id.Equals(id)).SingleOrDefault();
}
public IEnumerable<T> Get(IEnumerable<TId> ids) {
var idList = ids.ToList();
return All().Where(e => idList.Contains(e.Id));
}
public void Delete(T entity) {
UnitOfWork.CurrentSession.Delete(entity);
}
public void Update(T entity) {
UnitOfWork.CurrentSession.Update(entity);
}
}
public interface IRepository<T, in TId> : ICreate<T>, IRead<T, TId>, IDelete<T>, IUpdate<T> where T : Entity<TId> {}
public interface IDelete<in T> {
void Delete(T entity);
}
public interface IRead<out T, in TId> where T : Entity<TId> {
IQueryable<T> All();
T Get(TId id);
IEnumerable<T> Get(IEnumerable<TId> ids);
}
public interface ICreate<in T> {
void Add(T entity);
}
public interface IUpdate<in T> {
void Update(T entity);
}
internal class Person : Entity<string> {
public string Name { get; set; }
public int Age { get; set; }
}
internal class PersonRepository : BaseRepository<Person, string>, IPersonRepository {
}
internal interface IPersonRepository : IRepository<Person, string> {
}
I implemented
CRUD interfaces for my repositories so that a client can choose which operations it wants to interact with. If all a client needs to do is perform reads, then it can consume the
IRead<T> interface and opposed to a full fledged
IRepository<T>. That concrete implementation of
IRead<T> would still be able to inherit from
BaseRepository<T>, but would not be consumed as such. Using
dependency injection, you'd do something like...
Map<IRead<User>>.To<UserRepository>();
Then an
MVC controller or some dependant object would look like...
public class AccountController(IRead<User> userRepository) {...}
This concept is the
I in
SOLID for
Interface Segregation. Give the client only what it needs. Nothing more and nothing less.
I didn't think I'd need something for updates like
IUpdate<T> since most
UoW implementations will implement change tracking. For instance if you retrieve and entity from a
Raven or
NHibernate session and modify it, the changes will automatically be applied upon saving the session. But thent I thought about what happens in
ASP.NET MVC when we handle updates. Say the user goes to our update page and makes some changes to some text fields that represent and entity. The
ASP.NET MVC will automatically construct an instance of our entity or
view model and allow us to persist it. Their is a
TryUpdateModel that
MVC exposes on controllers, but what if you're mapping from
view model to
entity/DTO? There'd be no need to retrieve the entity from the
domain layer since you already have a copy of it in memory. I could be wrong on this. Maybe it's common practice to always find your entity, apply the necessary changes, and persist it. I'm not sure how most do it, but having
IUpdate<T> doesn't hurt right?
Implementing a Request Module for ASP.NET
Now I need a request module that knows how to initialize the session and spawn the
UoW.
public class UnitOfWorkModule : IHttpModule {
public void Init(HttpApplication application) {
application.BeginRequest += ApplicationBeginRequest;
application.EndRequest += ApplicationEndRequest;
}
static void ApplicationBeginRequest(object sender, EventArgs e) {
UnitOfWork.Start();
}
static void ApplicationEndRequest(object sender, EventArgs e) {
UnitOfWork.CurrentSession.SaveChanges();
}
public void Dispose() {
UnitOfWork.CurrentSession.Dispose();
}
}
Let me add that I borrowed the idea of this particular implementation of
UoW from
a blog on nhforge.com. I tweaked it to my liking. It's not perfect, but I'm content with it and it works for me. I'd never go so far as to deem this the ultimate implementation of
UoW.
The cool thing about our implementation is that we can switch from
Raven to
NHibernate with one line of code.
The bad thing is that we can't leverage any framwork specific goodies. For instance, the power behind document databases is that they perform lightning fast reads. This is accomplished via
indexes. In
Raven, we specifiy our indexes upon executing our queries, but there's no way for my
BaseRepository to do that unless it knows it's dealing with
Raven in particular. I'd have to cheat to do that and probably break my encapsulation by assuming certain things about the current
ISession at hand. Something like type casting it to an
IDocumentSession (
Raven specific).
Raven is smart enough to dynamically create indexes for us on the fly if it detects that we didn't specify one client side, and will eventually promote them to permanent indexes if we used them enough over a certain amount of time. Frankly you just need to be aware of what you're gaining and losing. You should analyze if the benefits of a clean and reusable design are worth the extra work it takes to be able to leverage all of your target frameworks features. Sometimes you can get away with declarative xml configuration independent of code, or decorating your classes with a specific attribute and having the runtime pick up on it; But that's a big maybe and a long shot in most cases. Regardless I thought this would be a cool idea and fun to implement.
Implementing Unit Tests For Raven
We're not done yet my friends. It's time for some
unit tests.
NUnit where you be?
[Test]
public void Person_Repository_Can_Save_Person() {
IPersonRepository personRepository = new PersonRepository();
var adubb = new Person { Age = 22, Name = "Antwan \"A-Dubb\" Wimberly \r\nIt's Okay To Not Hire A Senior Developer!! There Are Good Young Develpers Out There Too!!" };
personRepository.Add(adubb);
var id = adubb.Id;
var adubbFromRepo = personRepository.Get(id);
Assert.IsNotNull(adubbFromRepo);
Assert.AreEqual(adubb.Id, adubbFromRepo.Id);
Assert.AreEqual(adubb.Name, adubbFromRepo.Name);
Assert.AreEqual(adubb.Age, adubbFromRepo.Age);
personRepository.Delete(adubbFromRepo);
UnitOfWork.CurrentSession.SaveChanges();
}
Whoops!! Looks like
Raven doesn't allow us to call Equals to in the body of our
lamdas. Time to
refactor. We need to
override our base implementation of
Get(TId id); Let's make it
virtual and
override it.
public class RavenBaseRepository<T> : BaseRepository<T, string> where T : Entity<string> {
public override T Get(string id) {
return All().Where(e => e.Id == id).SingleOrDefault();
}
}
internal class PersonRepository : RavenBaseRepository<Person>, IPersonRepository {
}
I'm already noticing that my query is taking a rather long time to execute. This probably means
Raven isn't making
optimized reads. I'd expect things to execute a lot faster.
Anyway, let's run our test again.
That's strange. We didn't find any results. Something must be going wrong with my
Id. The problem is the entity is still
transient. That is to say, it hasn't been persisted yet. We need to submit our changes before performing our read. Let's
refactor our test.
personRepository.Add(adubb);
UnitOfWork.CurrentSession.SaveChanges();
var id = adubb.Id;
We told
Raven to persist the object before retrieving it. Let's try again.
Ok. I'm still getting an error. I probably shouldn't be messing around with my
Id property. That's
Raven's. Let's make one final change.
var adubb = new Person { Age = 22, Name = "Antwan \"A-Dubb\" Wimberly \r\nIt's Okay To Not Hire A Senior Developer!! There Are Good Young Develpers Out There Too!!" };
Aaaaand!! Nope. Still didn't work. You may have caught on now but if you haven't the problem is
inheritance.
Raven apparently can't pick up on the fact that I'm inheriting my
Id from my parent class
Entity. So now I have to redefine it in the person class like so.
public class Person : Entity<string> {
public new string Id { get; set; }
public string Name { get; set; }
public int Age { get; set; }
}
Alright. Things are working now according to my unit test and
Raven Studio. My
Add test passes. Now it's time to test
delete.
[Test]
public void Person_Repository_Can_Delete_Person() {
IPersonRepository personRepository = new PersonRepository();
var adubb = new Person { Age = 22, Name = "Antwan \"A-Dubb\" Wimberly \r\nIt's Okay To Not Hire A Senior Developer!! There Are Good Young Develpers Out There Too!!" };
personRepository.Add(adubb);
UnitOfWork.CurrentSession.SaveChanges();
var id = adubb.Id;
var adubbFromRepo = personRepository.Get(id);
Assert.IsNotNull(adubbFromRepo);
personRepository.Delete(adubbFromRepo);
UnitOfWork.CurrentSession.SaveChanges();
adubbFromRepo = personRepository.Get(id);
Assert.IsNull(adubbFromRepo);
}
This one worked right out of the box. No magic needed.
Get is next.
[Test]
public void Person_Repository_Can_Get_Person() {
IPersonRepository personRepository = new PersonRepository();
var adubb = new Person { Age = 22, Name = "Antwan \"A-Dubb\" Wimberly \r\nIt's Okay To Not Hire A Senior Developer!! There Are Good Young Develpers Out There Too!!" };
personRepository.Add(adubb);
UnitOfWork.CurrentSession.SaveChanges();
var id = adubb.Id;
var adubbFromRepo = personRepository.Get(id);
Assert.IsNotNull(adubbFromRepo);
personRepository.Delete(adubb);
}
And lastly
update. This one is pretty easy to test because of
change tracking so I have 2 implementations. The first works just fine.
[Test]
public void Person_Repository_Can_Update_Person_Without_Calling_Update() {
IPersonRepository personRepository = new PersonRepository();
var adubb = new Person { Age = 22, Name = "Antwan \"A-Dubb\" Wimberly \r\nIt's Okay To Not Hire A Senior Developer!! There Are Good Young Develpers Out There Too!!" };
personRepository.Add(adubb);
UnitOfWork.CurrentSession.SaveChanges();
var id = adubb.Id;
var adubbFromRepo = personRepository.Get(id);
Assert.IsNotNull(adubbFromRepo);
const string changedName = "Changed Name";
adubbFromRepo.Name = changedName;
UnitOfWork.CurrentSession.SaveChanges();
adubbFromRepo = personRepository.Get(id);
Assert.AreEqual(changedName, adubbFromRepo.Name);
personRepository.Delete(adubb);
}
But we run into problems with the second.
Looks like
Raven is forcing me to fetch my entity from the session before I can update it. It knows the entity is unattached. So I guess I could remove my implementation of
Update.
NHibernate however will properly convert my
Contains call to an
IN Clause; which is what I expect.
[Test]
public void Person_Repository_Can_Update_Person_When_Calling_Update() {
IPersonRepository personRepository = new PersonRepository();
var adubb = new Person { Age = 22, Name = "Antwan \"A-Dubb\" Wimberly \r\nIt's Okay To Not Hire A Senior Developer!! There Are Good Young Develpers Out There Too!!" };
personRepository.Add(adubb);
UnitOfWork.CurrentSession.SaveChanges();
const string changedName = "Changed Name";
const int changedAge = 19;
var id = adubb.Id;
// this entity didn't come from the session and thus is not being tracked. we're pretending like we've just
// populated this entity in our controller based on the view and are about to persist it.
var adubbFromRepo = new Person {Id = id, Age = changedAge, Name = changedName };
personRepository.Update(adubbFromRepo);
UnitOfWork.CurrentSession.SaveChanges();
adubbFromRepo = personRepository.Get(id);
Assert.AreEqual(changedName, adubbFromRepo.Name);
Assert.AreEqual(changedAge, adubbFromRepo.Age);
personRepository.Delete(adubb);
}
My last test if for
Get with an overload. Of course it failed because
Raven won't let me call
Contains during my query. I'll figure it out later though. It's 1am right now and I'm beat. Plus my hot pocket is almost done cooking.
public static class ObjectExtensions {
public static IEnumerable<TType> ToSingleEnumerable<TType>(this TType target) {
yield return target;
}
}
[Test]
public void Person_Repository_Can_Find_All_By_Id() {
IPersonRepository personRepository = new PersonRepository();
var adubb = new Person { Age = 22, Name = "Antwan \"A-Dubb\" Wimberly \r\nIt's Okay To Not Hire A Senior Developer!! There Are Good Young Develpers Out There Too!!" };
personRepository.Add(adubb);
UnitOfWork.CurrentSession.SaveChanges();
var id = adubb.Id;
var adubbFromRepo = personRepository.Get(id.ToSingleEnumerable()).FirstOrDefault();
Assert.IsNotNull(adubbFromRepo);
Assert.AreEqual(adubb.Id, adubbFromRepo.Id);
Assert.AreEqual(adubb.Name, adubbFromRepo.Name);
Assert.AreEqual(adubb.Age, adubbFromRepo.Age);
personRepository.Delete(adubbFromRepo);
}
Implementing NHibernate Support
We're going to make a context switch to NHibernate now. We'll start with a concreate implementation of the ISession interface for NHibernate.
internal class NHibernateSession : ISession {
static readonly ISessionFactory SessionFactory;
static NHibernateSession() {
// an expensive operation that should be called only once throughout the lifetime of the application. you'll typically see this in Application_Start of Global.asax.
SessionFactory = Fluently
.Configure()
.Database(MsSqlConfiguration.MsSql2008
.ConnectionString("Server=.; Database=NHPrac; Integrated Security=true;")
.ShowSql())
.ExposeConfiguration(x => {
// for our CurrentSessionContext. this has to be configured or NHibernate won't be happy
x.SetProperty("current_session_context_class", "thread_static");
// so the Product table can be exported to the database and be created before we make our inserts
var schemaExport = new SchemaExport(x);
schemaExport.Create(false, true);
})
.Mappings(x => x.FluentMappings.AddFromAssembly(Assembly.Load("Intell.Tests")))
.BuildSessionFactory();
}
internal NHibernateSession() {
// sessions are really cheap to initialize/open
var session = SessionFactory.OpenSession();
session.BeginTransaction();
CurrentSessionContext.Bind(session);
}
static NHibernate.ISession CurrentSession { get { return SessionFactory.GetCurrentSession(); } }
public void Dispose() {
// unbind the factory and dispose the current session that it returns
CurrentSessionContext.Unbind(SessionFactory).Dispose();
}
public IQueryable<TEntity> Query<TEntity>() where TEntity : Entity {
return CurrentSession.Query<TEntity>();
}
public void Add<TEntity>(TEntity entity) where TEntity : Entity {
CurrentSession.Save(entity);
}
public void Update<TEntity>(TEntity entity) where TEntity : Entity {
CurrentSession.Update(entity);
}
public void Delete<TEntity>(TEntity entity) where TEntity : Entity {
CurrentSession.Delete(entity);
}
public void SaveChanges() {
var transaction = CurrentSession.Transaction;
if (transaction != null && transaction.IsActive)
CurrentSession.Transaction.Commit();
}
}
There's nothing special going on here. Just your standard
Fluent NHibernate stuff and
NHibernate basics in general. If my usage of the
CurrentSessionContext class is unfamiliar to you then I'd suggest you get yourself a copy of the
NHibernate 3.0 Cookbook. It's got the latest
NHibernate best practices in it and was the basis of how I managed my
NHibernate session.
Before I go any further I want to note that
NHibernate won't let me call
Equals in my
Get(TId id) method so again I have to make a framework specific repository. Dangit!!
And yes I'm aware that
S#arp Architecture has a base
NHibernate and a base
Entity class (I think...), but I wanted to take a stab at creating my own. It probably looks identical to what's already out there but oh well.
// we'd probably have to make a separate one for id's of type int to support identity columns
public class NHibernateBaseRepository<T> : BaseRepository<T, Guid> where T : Entity<Guid> {
public override T Get(Guid id) {
return All().Where(e => e.Id == id).SingleOrDefault();
}
}
Next we'll build a
ProductRepository,
mapping file, and
Product entity.
public class Product : Entity<Guid> {
public virtual string Name { get; set; }
public virtual int InventoryCount { get; set; }
}
public sealed class ProductMap : ClassMap<Product> {
public ProductMap() {
Id(x => x.Id)
.GeneratedBy
.GuidComb();
Map(x => x.InventoryCount);
Map(x => x.Name);
}
}
internal class ProductRepository : NHibernateBaseRepository<Product>, IProductRepository {}
internal interface IProductRepository : IRepository<Product, Guid> {}
The
Enity<TId> class becomes...
public class Entity<TId> : Entity {
public virtual TId Id { get; set; }
}
Of course everything has to be virtual for proxy support so I had to make a slight modification to my base
Entity<TId> class.
I only wrote 2
unit tests this time around, because I'm more than confident that the functionality works. Earlier I ran into a problem with my
GetAll(IEnumerable<TId> ids) implementation of my
BaseRepository class due to constraints that
Raven enforces. I still have to come up with a clean work around, but we won't worry about that for now. This time I wanted to be sure my
GetAll overload would work so I tested it in addition to
Save. The tests both pass with flying colors.
The
Start method of
UnitOfWork becomes...
public static void Start() {
// CurrentSession = new RavenSession();
CurrentSession = new NHibernateSession();
}
[TestFixture]
public class ProductRepositoryTests {
[TestFixtureSetUp]
public void Init_Unit_Of_Work() {
UnitOfWork.Start();
}
[TestFixtureTearDown]
public void Uninit_Unit_Of_Work() {
UnitOfWork.CurrentSession.Dispose();
}
[Test]
public void Product_Repository_Can_Save() {
var product = new Product { InventoryCount = 12, Name = "A-Dubb's World" };
IProductRepository productRepository = new ProductRepository();
productRepository.Add(product);
var id = product.Id;
Assert.IsFalse(id == Guid.Empty);
product = productRepository.Get(id);
Assert.AreEqual(12, product.InventoryCount);
Assert.AreEqual("A-Dubb's World", product.Name);
productRepository.Delete(product);
UnitOfWork.CurrentSession.SaveChanges();
}
[Test]
public void Product_Repository_Can_Get_All() {
var product = new Product { InventoryCount = 12, Name = "A-Dubb's World" };
IProductRepository productRepository = new ProductRepository();
productRepository.Add(product);
var id = product.Id;
Assert.IsFalse(id == Guid.Empty);
product = productRepository.Get(id.ToSingleEnumerable()).SingleOrDefault();
Assert.IsNotNull(product);
Assert.AreEqual(product.Name, "A-Dubb's World");
Assert.AreEqual(product.InventoryCount, 12);
productRepository.Delete(product);
UnitOfWork.CurrentSession.SaveChanges();
}
}
And yea I should have followed
TDD and written my tests first and I surely could have
refactored my
units tests for reusability's sake; but I'm not gonna bother.
Conclusion
We started out with our common session interface for
NHibernate and
Raven to implement. The we made our
UoW and concrete
Raven based session implementation. That was followed by our strongly typed classes for
local storage and our core
domain layer base classes (
Entity and
BaseRepository). We then subclasses out
BaseRepository to make a
Raven specific implementation that stores
Entities with string based ids as
Raven requires. Since we plan to be able to use
Raven on the web, we made an
HttpModule that can be registered in
Web.config to initialize our session for each request made to our web application. And lastly, we wrapped things up with a few
unit tests, a concrete
ISession implementation for
NHibernate, and discovered some things about
Raven along the way. Specifically it can not pick up on and inherited
Id property and only a specific subset of methods are allowed to be executed within our
query calls/lamda expressions.
Well, that's it folks. As I mentioned before, the switch between
Raven and
NHibernate is a trivial but potentially problematic one,
but you'd at least have your core
domain layer in place for each framework. For one,
Id's in
Raven are string based, which is not the case in
NHibernate where
GUIDs tend to dominate. So switching would probably mean refactoring your
entities switching the
repository you
inherit from; which could certainly be a problem. Secondly, it makes it tougher to use framework specific features such as
indexes in
Raven when executing queries; which is one its most important features. Were it not for the aforementioned constraints, you'd be able to switch from
Raven to
NHibernate with one line of code. That's why I build this post to begin with. I thought I could pull it off, but my
unit tests told me otherwise. Either way, this was really fun to implement and I learned a lot. I hope this post proves to be helpful to a lot of people and can maybe serve as a catalyst for future implementations.
This is quite a bit of code so I should be uploading to
github any day now.
I'll follow up this post by implementing a cool implementation of read only mode in
ASP.NET (web forms). Pretty cool right?
Cheers!!
