There have traditionally been two ways of specifying NHibernate queries: HQL and the criteria query API.

Although I have an easier time deciphering HQL, which is basically a SQL-like string using classes instead of tables, I’ve tended to use the criteria API because it was somewhat strongly typed and thus easier to maintain with the help of refactoring tools like ReSharper.

Thanks to the new NHibernate LINQ provider, I can now work in a mode that is not only more type safe, but also much more readable.

Look at these before and after queries and judge for yourself:

Before (Criterion API)

   1: public IList<Call> GetCallsByDate(DateTime beginDate, int interpreterId)

   2: {

   3:     ICriteria criteria = Session.CreateCriteria(typeof(Call))

   4:         .CreateAlias("Customer", "Customer")

   5:         .Add(Restrictions.Gt("StartTime", beginDate))

   6:         .Add(

   7:            Restrictions.Or(

   8:                 Restrictions.Lt("EndTime", DateTime.Now), Restrictions.IsNull("EndTime")

   9:                 )

  10:             )

  11:         .Add(Restrictions.Eq("Interpreter.Id", interpreterId))

  12:         .AddOrder(Order.Desc("StartTime"))

  13:         .AddOrder(Order.Desc("Customer.Name"));

  14:

  15:     return criteria.List<Call>() as List<Call>;

  16: }

After (LINQ to NHibernate)

   1: public IList<Call> GetCallsByDateWithLinq(DateTime beginDate, int interpreterId)

   2: {

   3:     var query = from call in Session.Linq<Call>()

   4:                     where call.StartTime > beginDate

   5:                         && (call.EndTime == null || call.EndTime < DateTime.Now )

   6:                         && call.Interpreter.Id == interpreterId

   7:                     orderby call.StartTime descending, call.Customer.Name

   8:                     select call;

   9:

  10:     return query.ToList();

  11: }

Apparently the NHibernate guys are still working on a full featured LINQ provider for a future version of NHibernate, but decided that the LINQ provider in the contrib project has been tested enough and used in enough production systems to promote it to RTM status.

The one thing I did notice when peeking at the SQL in Profiler is that the Linq provider produced an extra join that the regular Criteria API figured out wasn’t necessary because I was just referencing the foreign key column in the where clause. I’m guessing that minor differences like this will be addressed in the next version of the provider.

In the meantime, I’m still hooked enough to want to use this approach instead.

If you want to give LINQ to NHibernate a test run, just download and reference the one required dll here (make sure you’re using the same version of NHibernate).

If you’re still not comfortable with LINQ sytnax, here’s a simple example based MSDN tutorial to get you started.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

If I’m stuck in one of those loony shops that mandates that all data access has to be done via stored procedures, will NHibernate buy me much? In other words, if the tool’s purpose is to eliminate me writing SQL, but I have to write SQL anyway, is there a point?

I’ve only been using NHibernate for about 6 months and am barely struggling to emerge from the newbie stage, but my gut instinct says that you would loose about 90% of the benefits if you only ever used sprocs with NHibernate.

However, if I were in my friend’s situation I would probably still use it.

Why?

The main reason isn’t because of time or productivity savings, but rather because I would bet on the long-term viability of NHibernate and ORM’s in general.

NHiberate is already pretty mainstream and becoming more popular every day. The fact that Microsoft is now fully invested in the ORM space with the Entity Framework means that it will only be a matter of time before the traditional sproc-only mentality finally disappears from even the most conservative software shops.

In the meantime, I’m guessing that I would be able to speed up that process by introducing NHibernate into my application and my workplace even it would be under less than optimal circumstances and not save me much (if any) time in the short term.

Based on my experience with human nature, I’m betting that once NHibernate is in the dev and production environments for a while, the other developers and administrators would get used to it and eventually loosen up enough to let me start mapping directly against tables. It’s a slight gamble, but one based on pretty predictable human behavioral traits.

If nothing else, it’s much more convincing to show someone a proof of concept based on an existing app in production that you only have to slightly modify rather than on a silly Northwind example.

As far as more technical reasons, I leave this up to the more advanced NHiberate using reader to comment on. My sense is that you could still cut down on some tedious mapping code (right to left assigment stuff), but using Fluent NHibernate’s Auto Mapping feature, but I haven’t tried this out yet on sprocs so that may be (at least for now) a dead end.

Are there any other compelling reasons to use NHibernate if you worked in a shop that mandated using only sprocs for data access?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Although I feel perfectly comfortable in a set-based world writing SQL, it has traditionally been one of my least favorite areas of coding. Besides being relatively repetitive and tedious, at least when it comes to basic CRUD operations, sprocs are much more difficult to handle when it comes to source control, versioning, debugging, and unit testing.

For example, at my last job we were tasked by auditors to come up with a build and deployment process that included version traceability and rollback capabilities. It was pretty easy to put together an acceptable solution for assemblies, since automatically versioning dll’s in a trusted way is simple via the AssemblyInfo and rolling them back is trivial since everything is contained in a manageable number of dlls that simply need to be copied from one folder to the next. When it came to sprocs, however, the best we could offer auditors was some hackery around adding comments about the version at the top of each sproc definition file along with a big disclaimer that there was no guarantee that files were not modified by DBA’s along the way.

At my current job, database code causes us even more trouble because the database is larger and contains more sensitive data (thus making restores more difficult), there is a heavier reliance on shared code, and only the deltas of database code are currently under source control. It feels like I am constantly tracking down some ghost bug that is caused by my local database schema somehow being out of sync with the codebase.

Despite these misgivings, I’ve dutifully followed the traditional Microsoft recommended best practice of funneling all data access through sprocs up until recently because sprocs were supposedly faster, more secure, and provided a beneficial layer of abstraction.

Although I have heard several arguments against sprocs in the last several years, I recently embarked on a more thorough investigation while trying to convince my team to switch over from using an in-house code generation\sproc-based solution for data access to using NHibernate\ActiveRecord. Here are a few resources I found that present good counter arguments against the conventional sproc wisdom.

1. Stored procedures are bad, m’kay?: This classic post that was written by Frans Bouma of LLBLGen fame in 2003 spawned quite the flame war on the topic. Most notably, Frans counters the “Sprocs are faster because they are compiled” argument by quoting passages from the SQL Server BOL documentation that clearly suggest otherwise. He also counters security arguments by pointing out that parameterized queries prevent SQL injection just as much as sprocs and that assigning permissions to views and roles provide just as much protection as assigning execute rights on sprocs.
2. Who Needs Stored Procedures, Anyways?: This is also an older post from Jeff Atwood where he nicely summarizes the negative aspects of SQL when compared with a traditional coding languages and came up with the quotable phrase “Stored Procedures should be considered database assembly language: for use in only the most performance critical situations”. I definitely think that some developers are reluctant to embrace ORM’s for the same reasons that many old C++ programmers scoffed at the idea of letting the CLR garbage collector manage memory for them instead of manually doing it themselves with raw pointers.
3. Why I do not use Stored Procedures: Jeremy Miller dismisses performance arguments by declaring them instances of premature optimization and elaborates on all the problems caused by sprocs when it comes to maintainability, testability, and architecture. He also points out that the touted benefit of allowing DBA’s to make changes is actually a dangerous practice since it represents a breaking API change from the application’s point of view and thus should go through thorough regression testing before any DBA should be allowed to make changes.
4. Foundations of Programming – Part 6 – NHibernate: Besides offering a nice introduction to NHibernate, Karl Sequine provides a nice summary of the historical sproc debate, including a counter point for the increased network traffic argument, which he says is a moot point since most traffic occurs between a app and database servers sitting on the same internal GigE networks where bandwidth is fast, plentiful, and free.
5. DotNetRocks ORM Smackdown: For a more balanced debate, listen to this podcast episode (or download the transcripts) where Oren Eini and Ted Neward face off over the value of ORM’s in the software industry. Be sure to check out the commentary on the episode in the comment section of this Ayende post as well as the rebuttal in this post by Ted Neward.

In my opinion, one of the strongest denunciations of traditional sproc dogma comes Redmond itself, which seems to be straying from its original sproc recommendations in favor of a more more dynamic SQL generation world-view with its recent release of LINQ to SQL and the Entity Framework.

If you follow the open source world or program in some language other than .NET, then you’re bound to feel a little smug right now because ORM’s have been around for a long time. In fact, I have a vivid memory from 6 years ago of a co-worker who was fresh from the Java world being dumb-founded that Microsoft didn’t have any ORM solution. He was used to using HIbernate and the thought of manually mapping database tables to domain objects was hard for him to grasp. Even in the .NET open source world, I’ve been reading blog posts that sing the praises of NHibernate and IBatis.NET, two popular .NET ORM ports, for several years.

On one hand, Microsoft’s entrance into the fray is good news for ORM enthusiasts since it means that a larger audience of developers will begin to see the technology as legitimate. On the other hand, Microsoft clearly has some catching up to do in this space, so you might want to think twice about starting off with Microsoft’s offering rather than one of the more proven open source or third party alternatives.

If you are a .NET developer and new to ORM’s, then I recommend starting out with Castle’s Active Record, which you can learn in less than an hour by reading this Getting Started with Active Record tutorial. My co-worker’s were reluctant to try NHibernate because of the perceived learning curve and the plethora of mapping files required, but they quickly agreed to use Active Record after only a short demo.

If you are a POCO purists, which means that you want to keep your domain objects free of any non-business related concerns (such as persistance), then you’ll want to follow the repository pattern using the ActiveRecordMediator class rather than inheriting from ActiveRecordBase like the tutorial shows. Some of the more experienced ORM users seem to see ActiveRecord as more of a gateway drug to NHibernate and ultimately prefer to forgo the conveniences offered by the ActiveRecord layer in favor of the increased flexibility and loosely coupled design offered by dealing directly with NHibernate instead.

Regardless of the approach taken, I definitely no longer believe that sprocs should play any significant role in any application. The current mandate in the software industry is to strive to lower costs by increasing developer productivity and ORM’s clearly help to do this by eliminating the need to write and maintain countless simple CRUD sprocs.

It’s definitely time for all of us .NET developers to abandon our convention sproc wisdom and start playing catch-up with the rest of the industry when it comes to using ORM’s.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Today I worked on a sproc that involved over a dozen DML statements (it was a utility sproc to handle security and setup steps for developers as part of our build process, so there is no need to chastise me about it being bad design to have so much logic in the database). The thought of copy-pasting dozens of tedious procedural error handling code snippets was so distasteful to me that I decided to do a quick verigoogle. Verigoogling is my freshly coined word for challenging one of my assumptions through google. I was delighted to discover that this new Try/Catch syntax is available to the masses to be used in plain vanilla sprocs. Instead of checking the @@error variable after each statement, we can now be lazy..er..I mean concise and consolidate all the error handling code into the catch block like we’re used to doing in good ole’ OOP code.

For those of you like me who haven’t been taking advantage of this new feature yet, here is some sample code that demonstrates the how easy it is to use. As for the rest of you, please restrain yourself for making fun of me and go verigoogle one of your own assumptions.

BEGIN TRY

      BEGIN TRANSACTION

          DELETE FROM table1

          DELETE FROM table2

      COMMIT

END TRY

BEGIN CATCH

    IF @@TRANCOUNT > 0
           ROLLBACK

     DECLARE @ErrMsg nvarchar(4000), @ErrSeverity int
     SELECT @ErrMsg = ERROR_MESSAGE(),
     @ErrSeverity = ERROR_SEVERITY()

     RAISERROR(@ErrMsg, @ErrSeverity, 1)

END CATCH

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Apparently Microsoft is still a little sensitive from being 2 years late on the last version because Dave Campbell spent the first 5 minutes of his Tech Ed presentation explaining how they have re-engineered their process to ensure that the next version will be delivered on schedule. For example, they will no longer be checking in features into the CTP codebase unless they are fully completed so early CTP’s will only include a few fully functional features rather than most of the envisioned features in a half-baked state.

Well, whenever we do get the next version, here are a few features that caught my eye.

• Merge statements (aka upserts) – a nice efficient syntax for loading data into a data warehouse that will allow you to specify either an insert or update based on whether or not a record exists.

MERGE INTO FactTable F
USING TransactionTable T ON T.OrderID = F.OrderID
WHEN MATCHED THEN UPDATE
SET F.Quantity = T.Quantity

• Table Valued Parameters – allows you to pass in a result-set as a parameter to a sproc of udf.
• Resource Governor – helps prevent runaway queries that can bring down your server. This is especially helpful if you work someplace that allows ad hoc querying against transactional systems.
• Declarative Management Framework – the Tech Ed webcast showed a demo where a create table statement was prevented from running in Query Analyzer because it violated a policy that had been set up regarding ownership and schemas. Another demo showed a database in SMS with a warning icon because the shrink DB setting had been enabled that violated a configuration policy.
• Dynamic Development – a rather vague term, but one example was given that described tagging columns with metadata tags such as ‘sensitive’ that would then allow you to do queries to track these categories and also apply policies such as only allowing users to query these columns through a secure connection.
• New Data Types – The filestream data type allows for a best-of-breed approach to managing blob data that would blend the efficiency of the file system with the manageability of the database (backup, restore, querying). Location and Spatial data types allow for built in support for geo-mapping features.
• Change Data Capture – a good way to appease the auditors by tracking and exposing changes though a relational interface.
• Encryption – Also an auditor pleaser. It is supposed to be configurable without any application changes required.
• Performance Enhancements and Tracking – The biggest gains appear to be in start join optimization and data compression, which takes advantage of the fact that SQL Servers are rarely CPU bound. There are also supposed to be a plethora of performance monitoring tools, which we currently rely on Quest tools to provide us.

I’m looking forward to playing with some of these features. With any luck its name will reflect reality and the upgrade path will be easier than it was with

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

In hindsight, the migration went fairly smoothly but it was definitely not a trivial process, nor was it something that I would want to repeat any time soon. It definitely requires some advanced planning and organized regression testing. I thought I would jot down a few lessons that we learned before I completely block this experience out of my memory.

Here are some quick background stats (mid-sized bank):

1. Apps Tested: 40
2. Technologies supported: .NET 2.0, 1.1, 1.0, Classic ASP, VB6, PowerBuilder, Access 97
3. Databases: 25
4. Total Tables: 2400
5. Total DB Objects (sprocs & udf’s): 3500
6. DTS packages: 100
7. Server implementation: Clustered Quadzilla running on 32 bit Standard Edition, separate Reporting Server
8. Total required object changes: 40-50

Lessons Learned:

1. The upgrade wizard was helpful but not full-proof. It caught about 60% of the changes we had to make. If you have separate reports or application logic that runs on specific days (i.e. end of month, start of month, end of quarter, etc), make sure you run profile traces on those days and then use the trace files as input for the upgrade adviser.
2. Script out all the sprocs and udf’s and then run the ddl scripts against an upgraded test server. We caught another 20% of the problems through the syntax errors we got when trying to recreate these objects.
3. Set up an organized regression test of your critical apps, especially if your business has a low tolerance to risk. The last 20% of our changes were only caught through testing because of dynamically generated SQL or SQL that was embedded within the applications rather than stored as objects within SQL Server.
4. Carefully review all proposed sproc changes and when possible compare before and after result sets with a tool like RedGate BeyondCompare. Most of the changes we had were syntax related and easily fixed, however we had to redo a few changed sprocs because of some misunderstandings of how the old *= join syntax worked.
5. Be on guard for a few hard to spot errors that might show up later in production. For example, this excerpt from one of our udf’s actually concatenated multiple rows together in SQL 2000, but only returned the first row in 2005. The only way we figured this out was that someone reported that a few of our app generated pdf documents were missing several paragraphs.

 

 

   1: select @para = @para + cast(dgp.Paragraph as varchar(7000)) + '

   2:

   3:             from DocumentParagraphs dgp

   4:

   5:             where dgp.ReportID = @ReportID

   6:

   7:                         and dgp.ActiveFlag = 1

   8:

   9:             order by dgp.ParagraphOrder

6. Do not rely on 8.0 compatibility mode as a safety net. Dropping back into 8.0 compatibility mode did not make the problems we found magically work.
7. If you have to move many DTS packages to a new machine, be prepared for some mind-numbing, tedious work. Each package had to be moved manually with lots of GUI clicks and all inner packages had to be re-selected due to GUID issues. Despite this headache, the DTS process was much smoother than expected and we didn’t have to make any code changes within the packages. We did experience some additional flakiness with SQLMail, but we’re not sure if that is related to SQL 2005 or moving from a single server to a cluster.
8. Beware Legacy Apps – If you have to support an old version of a defunct language like PowerBuilder, make sure that you are nice to the only guy who can support it. It turns out that we really didn’t have one of those guys anymore so a couple of us were forced to stumble around in the IDE for the first time ever in order to search for the offending embedded SQL while under deadline pressure. NOT FUN!
9. Don’t call undocumented functions! An old C++ module used by a couple of our legacy apps uses pwdcompare(). We finally got it to work but only by seriously elevating the application’s account permissions.
10. Access wasn’t so bad – Contrary to all expectations, we really didn’t have any problems with linked tables within our Access databases even though we were stuck on a really old version (Access 97). I expected this to be a nightmare, but it wasn’t.

Despite these hassles, the migration was definitely worth the effort for us. We were running up against a memory limit imposed by SQL Server Standard edition with our old server and were starting to experience some painful performance problems. SQL 2005 allowed us to upgrade to a much more powerful machine without having to pay the additional $180,000 in licensing fees that it would have cost us to upgrade all of our servers to the SQL 2000 Enterprise Edition which had support for additional memory.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.