This project has moved. For the latest updates, please go here.

How is this different from NHibernate + Fluent NHibernate?

Jun 13, 2009 at 5:03 PM

What would you say is the most compelling reason to use Ndb instead of just writing unit tests in a NHibernate (or NHibernate + Fluent NHibernate) project like I do now?

I'm not saying your library is better or worse than NHibernate/Fluent NHibernate.  I'm genuinely curious why I might use Ndb instead of my current technique of including a unit test in my test project that runs a method (VerifyDatabase) that the POCO entities in my project properly reflect what is in the underlying database schema.

Jun 15, 2009 at 8:40 AM
Edited Jun 15, 2009 at 8:41 AM


Thank you for your question.

Ndb provides different methodology. Let me describe it.

The primary part of every application is business logic. Depending on business logic we design database structure. From this point of view, Ndb provides the following advantages:

  • Ndb generates database structure based on your classes; therefore since you've synchronized the source code, you have synchronized database structure also.
  • All test data for your Unit tests can be stored in Excel sheets, and you can easily import that data to database. (In big systems there are problems then we need to test manually some functionality in front-end which required many data in database and Ndb is solution for this situations)

For example if you use continues integration:

  • Your unit tests will create database structure and import (or generate) test data needed for them.
  • After success build, all test data required for testers (to start work on your test instance) will be imported (for example from Excel). 
  • Also you can use above import script in programmers workflow. Programmer should have 2 databases, one for unit tests and one for the "classic" tests (then hi can manually check is application work) so after each update them will run tests. And one of the tests will update database structure and import (or generate) test data into it. So programmer will be sure that all functionality is working properly and he can immediately start to work on his task.
  • If you have production server you still need "VerifyDatabase" tests to check your production database. And you can synchronize it structure using Ndb functionality.


As for you question, I think that you don't have any goals to migrate right now. But I believe, that someone who needs an lite and easy solution can prefer Ndb.

Feel free to contact me if you have any questions or thoughts.