I'm currently working on some small projects and an enterprise level case study project where I decided to use SubSonic which is a lightweight open source ORM for .NET led by Rob Conery. I can say that SubSonic is really lightweight and is really easy to use, but as might be expected has some minor configuration overhead. SubStage developed by Eric Kemp is a must have if you are using SubSonic, but this tool lacks a very important feature IMHO. All your subsonic related project configuration is kept inside a predefined MasterStore.xml file which means you only have a single file for all your subsonic projects. In this scenario it is not easy/handy to attach your substage configuration to your project source code.

To overcome this problem I modified SubStage source code (built against SubSonic 2.2) and added "Load Master Store" and "Save Master Store As" File menu items. I posted the patch to Eric Kemp but I do not know if the patch will be applied in newer version so I publish both compiled SubStage and the Subversion Patch file.

Downloads

SubStage_2.2_With_MasterStore_LoadSave.rar (1.69 mb)

SubStage_Patch_AliOzgur.patch (242.82 kb)

CodeProject

Based on my previous article Artem Smirnov[^] posted a question about how to test a Repository(DAL) method in a project using Nhibernate as ORM. Here is his question

"I wanted to unit test a similar, but more common, problem: a Repository method. I.e., create a test Order for a particular date, and test that the FetchOrdersByDate method returns this order if the date matches. My guess was that I could just create an Order, attach it to the session without saving it to the database, then somehow stub the database and make NH fetch it from the cache. After doing a lot of search, I discovered that this is impossible, so I had to hit the database for every test. Given that NH looks extremely flexible, i.e., Interfaces everywhere, this is kind of strange.."

Here is my answer

The problem related to testing a Repository method is a very common one and people suggest different solutions to this problem. Here are some of them

* Mock your Repository method by using a Mocking library or by hand. But this suggestion is not valid all of the time. If you have native SQL or use NH Transformers to produce DTO's mocking is not an option.

* Use an in-memory database like SQLite for your tests. But if you have native sql or develop against a legacy database or use part of a legacy database you can not follow this approach

* Take script of your production database and create an empty test database. Run your tests against the test database. This method also have some drawbacks, to name few, tests take longer to run, you have to keep your test database up to date with the live one, you have to deal with some phantom objects not directly managed by your domain ( for example your domain contains Instructor class just for integrity reasons and you do not have code to deal with Instructor instantiation because you do not actually need this piece of function. But somehow you have to create Instructor objects for testing). You can solve the first two problems with Continuous Integration, but the later can be tricky to solve. However this last approach has one big outcome, that is, you will likely have failing tests if something goes wrong with your database.

I personally tend to follow the last approach for NH specific testing and write pure unit tests otherwise. 

CodeProject

Download NHibernate.Caches.Testing.zip (24.75 kb)

Motivation

It has been a long time since the last time I dropped a new entry in my blog. I was very busy with our new project and at last we finished coding and moved to Acceptance Testing phase. That new project was a little bit challenging from architectural point of view. Some challenges to name were

• We had to develop against a legacy database
• We had to replace an existing system with a new one, it was a little bit problematic process to introduce some new concepts
• Our system was designed targeting a small part of the legacy database, hovewer that part was accessed by some external processes/systems bringing some synchronization issues.
• We placed very strict code coverage and testing goals

In this blog entry I will try to share a very specific problem, writing good tests for NHibernate Level2 caching related functionality, we experienced and how we solved that problem.
More...

Here is aother strange problem related with NHibernate

The Problem

I have a Parent class and two child classes Child1 and Child2 mapped to different tables on the database.
Lets assume that we specified cascade='all' for child bags defined on Parent.hbm.xml. Sample workflow of instantiating parent and child objects is as the following

- Create a parent object.
- Insert 2 Child1 instances to child1 bag
- Insert 3 Child2 instances to child2 bag.
- Flush the session
- Refresh parent object
- We get 6 instances for each child bag (child1 and child2). But we expect 2 Child1 instances in child1 bag and 3 Child2 instances in child2 bag.

Ther problem is : NHibernate performs left outer join on Child1 and Child2 tables when Refresh is called for the parent object. This is unaccaptable, I think NHibernate should initialize child collections with seperate selects commited to the database, or may be distinguish the duplicated child instances automatically in the collections. (using idbag instead of bag is not an option)

Download the test case

• NH1472.rar (1,12 mb)

Requirements

•  NHibernate.Burrow

Watch This

•  NH-1472

I discovered this problem while developing a new system with the latest NHibernate.Burrow distribution (which in turn uses the latest NHibernate distribution).I spent some time Googling around to check if anyboy else met the same problem and found some entries but none of them specified exactly why this failure was happening and how we can solve this problem.
More...

GoF book says that "Observer pattern should defina a one-to-many dependency between objects so that when one object changes state, all its dependenst are notified and updated automatically". Subscribing to RSS feeds is a nice analogy.  You subscribe to RSS feeds to show interest and you become an observer who demand for notification and RSS feeds become the subject and are responsable for providing information to all subscribers. I think this bit of information describing the pattern is enough, now lets see how we implement observer pattern.
More...

I believe Factory Pattern is one of the most known pattern in development community. Simply Factory Pattern states that we have a factory object which is used to create other objects. But GoF specification for the Factory Pattern is a little bit different. GoF book says that "We should define an interface for creating an object, but let subclasses decide which class to instantiate."
More...

Download Source(23,52 kb)

We have different kind of vehicle implementations inherited from an abstract Vehicle class. Our code looks like this

C#-Code: Inital version of our abstract Vehicle class and its concrete implementations

001    //Abstract Vehicle class
002
003    public abstract class Vehicle
004
005    {
006
007        public abstract string Description { get; }
008
009
010
011    }
012
013    
014
015    //Concrete implementation
016
017    public sealed class Car : Vehicle
018
019    {
020
021        public override string Description
022
023        {
024
025            get { return "Car"; }
026
027        }
028
029    }
030
031
032
033    //Concrete implementation
034
035    public sealed class Helicopter : Vehicle
036
037    {
038
039        public override string Description
040
041        {
042
043            get { return "Helicopter"; }
044
045        }
046
047    }
048
049
050
051    //Concrete implementation
052
053    public sealed class Jet : Vehicle
054
055    {
056
057        public override string Description
058
059        {
060
061            get { return "Jet"; }
062
063        }
064
065    }

Suppose that our client wants to rent these different kind of vehicles and print vehicle information plus rental specific info such as FromDate, ToDate and the customer's name. We could implement this requirement by adding those new properties to our base Vehicle class in order to meet our customer's need. We also have to modify our concrete Vehicle classes so thet they can provide rental information through their Description property.

Here is our modified Vehicle class More...

I'm sure that you have already heard at least one of the following common design/development tips

• Seperate out parts of code that will be subject to change over time from the rest of your code
• Use has-a relationship instead of is-a relationship where possible, that is prefer composition over inheritance

Strategy pattern helps us to realize these tips in our designs. By applying the Strategy Pattern we move our algorithm implementations, which are possible source of maintainance issues, away from the more stable source code.

Download

GoF_Patterns_Strategy.rar (19,76 kb)

Recommended Reading 

Design Patterns For Dummies by Steve Holzner 

Example Implementation 

In our sample scenario we have different kind of vechicles all supporting some kind of Go behaviour. More...