OR/Ms are flawed…

…but they’re still better than the alternative which is to either fill your code with SQL statements or write and maintain a load of stored procedures. Why do I think OR/Ms are flawed? Because their purpose is to shield the developer from having to deal with the relational model and SQL in favour of an object model. In other words, provide an abstraction. However, they don’t quite get there as you do still need to know and use SQL (or worse, in the case of NHibernate, HQL which kind of mixes a SQL-like syntax with objects in place of tables).

NHibernate is a powerful weapon in a good developer’s arsenal. Unfortunately, its impact can be even more powerful in the wrong hands and can lead to very poor performance if you are not aware of what’s going on under the hood. I once worked at a company who saw NHibernate as a silver bullet but no one, not even the team lead understood it. They thought they we’re cutting edge and any problems they had we’re just down to the complexity of the domain they we’re working in. Needless to say, I didn’t stay there long, and last I heard, NServiceBus was their current flavour of the month! Anyway, the point is, they didn’t understand the tool or the SQL it generated which is key to getting the best out of it. In fact, it’s vital and this is the reason the abstraction doesn’t quite work because there is still a responsibility on you the developer to ensure that you are getting what you expect. An OR/M doesn’t mean you can forget about SQL and relational data models but there are many who think it does. And when the application is performing poorly it’s more than likely that the OR/M will get the blame.

So if we agree that you still need to understand the SQL produced by the OR/M then why not just write it all by hand in the first place, whether inline or with stored procs? Each option should be considered on it’s own merits of course but personally speaking, my preference would be a combination of approaches. I would use stored procs only as a means for returning view model data through “query” objects (using say, a lightweight Micro-OR/M such as Dapper). This data is “shaped” to fit how it is presented on screen. When I need to initiate an action on the domain I use a full blown OR/M (yes, NHibernate) for domain model persistence through “command” objects. A kind of poor man’s CQRS approach. These days I even go as far as interacting with NHibernate sessions directly instead of through the more common Repository approach as I constantly look to simplify my designs.

OR/Ms are not perfect and they’re not the answer to all our data persistence problems but they’re the best we currently have in the relational world and to me, preferable to hand rolling it all. Whereas in the past NHibernate would have been my only data access strategy for the entire project, I now see it as best suited to the “command” side and not used at all on the “query” side. Yes you can ignore OR/Ms altogether and do it all by hand but you’d be missing some important benefits. But in order to understand what those benefits are you need to invest some time learning your OR/M of choice, what its strengths are as well as its weaknesses. Only then can you make an informed decision. To not even consider them is an even bigger flaw.

OR/Ms are flawed…

Rotating a Bitmap in Mono for Android and MonoTouch

In a post last year, I wrote about a need I had to display a bitmap received from a web service but rotated by 90 degrees. This was for an Android application I was writing at the time using Eclipse and Java. As I recently stated, I’ve been looking at using C# to build iOS apps and decided to go the whole hog and checkout Mono for Android too. So I began by porting that application to Mono for Android which took around a week. Now I’ve nearly finished porting it to MonoTouch, the iOS equivalent. I can’t express how much I love the ability to use C# to write for these two platforms. Everyone associated with all things Mono should be congratulated for a terrific achievement, especially when you consider that even Microsoft are using Mono to write iOS apps now! Who’d have thunk it? :)

Anyway, for completeness I thought I would show the rotating bitmap code again but this time using C# code for the Android and iOS flavours of Mono. Hope it’s of use to someone out there.

Android:


// assume something hands us a bitmap
Bitmap myBitmap = GetImageFromWebService();

// get the width and height of the current view
Display d = WindowManager.DefaultDisplay;
int x = d.Width;
int y = d.Height;
	              
// scale it to fit the screen
Bitmap scaledBmp = Bitmap.CreateScaledBitmap(myBitmap, y, x, true);
	       
// create a matrix, rotate it anti-clockwise by 90 degrees
Matrix matrix = new Matrix();
matrix.PostRotate(-90);      
	       
// create a new rotated bitmap using the our original bitmap and the matrix measurements
Bitmap rotatedBmp = Bitmap.CreateBitmap(scaledBmp, 0, 0, scaledBmp.Width, scaledBmp.Height, matrix, true);    
	       
return rotatedBmp;

iOS:

	 

// assume something hands us a bitmap
UIImage myImg = GetImageFromWebService();
       
SizeF newSize = new SizeF(myImg.Size.Height, myImg.Size.Width);
	
UIGraphics.BeginImageContext(newSize);
CGContext ctx = UIGraphics.GetCurrentContext();
			
ctx.TranslateCTM(myImg.Size.Height, myImg.Size.Width); 
			
// scale
ctx.ScaleCTM(1f, -1f);
			
// rotate anti-clockwise
ctx.RotateCTM(1.57079633f);
			
// draw a new image with the same size
ctx.DrawImage(new RectangleF(0, 0, myImg.Size.Width, myImg.Size.Height), myImg.CGImage);
UIImage rotatedImage = UIGraphics.GetImageFromCurrentImageContext();
	
UIGraphics.EndImageContext();
		
return rotatedImage;

To be fair, the Android version is not that different from before (as you’d expect really) what with Java and C# being of similar syntax. The iOS version however is quite a bit different and perhaps a little bit more involved but it’s still fairly easy. You can experiment with the values passed to the various CTM (current transformation matrix) methods or change the size of the newly drawn image in the DrawImage method to see how they affect the resulting image display.

As for why I rewrote the Java based app in Mono C# well, for one C# is IMHO a nicer language than Java, and two, I extracted the business logic out into a separate assembly which is now shared between both the Android and iOS applications which means I only have to add new features or fix bugs in one place. It’s also been a lot easier and quicker to create the iOS version of the app than I’m sure it would have been if I had gone down the Objective-C route.

Rotating a Bitmap in Mono for Android and MonoTouch