Archive for the ‘Programming’ Category

NHibernate and Entity Framework Battle it Out in the Real World

Wednesday, December 3rd, 2008

The scene: a company division with no prior in-house experience using any ORM of any kind. A really, really legacy database-the kind with many composite keys, fields with mystery names, uneven use of enforced keys, etc. Currently, access done through ADO teamed with stored procs containing dynamic sql involving string concatenations (horrible for speed, security and my sanity among other things)

The mission? Given the constraint of not being able to change the underlying database aside from adding on some views, build a clean, modern app to eventually replace a legacy app that’s creating significant maintenance pain.

Early on, the team decided to lean toward use of an ORM-several team members had had positive past experience with ORMs, and it seems to be the way the industry was headed. However, that still left a choice-which ORM? The choice was quickly whittled down to NHibernate and Entity Framework. We ran two small parallel spikes, and ended up with a few thoughts about working with each:

First, we picked 3 or 4 tables to map to with both technologies, wrote up some simple classes, and then set about setting up persistence through an ORM-agnostic repository via both mappers.

NHibernate’s mapping files are relatively easy to read, but there’s no GUI to write them for you. It lets you write your classes and then work on your mappings separately afterward. The classes are clean POCO. NHibernate requires some code modification (virtual/overridable) and works better with some child-to-parent mappings that don’t seem like they should need to be there, but generally, modifications needed are minor. Repository is straightforward, and there’s lots of helper code online to do the legwork. Not tested, but it’s got sophisticated caching built-in.

Entity Framework was from Microsoft and had a GUI. The classes were autogenerated in one direction, from the database to the GUI to the classes… non-mapped properties caused errors-the proper place to put such artifacts was in a separate partial class file for the class-looking at the autogenned class, it was VERY clear you were not supposed to touch it, and probably not supposed to look at it.. this left the class spread across your partial and the gui. In addition, there were tight EF dependencies on these domain objects. Not to mention, after working with the GUI, I got the strong feeling that the GUI would not be able to handle complex scenarios, leaving us working with the raw verbose and complicated (and not really designed to be hand-edited) mapping xml. A pre-written class doesn’t seem to be able to be used easily-at least, we were exploring the usefullness of the gui, which left us to recreating the pre-written classes via the gui. It wasn’t clear if it was possible to mark a class as read-only, and code wouldn’t even compile if fields required in the DB were not mapped. Repository pattern was a bit more work-less guidance online… not sure if that’s because EF is so incredibly new, or because EF users are generally not as familiar with this pattern… in any case, it was a bit more tweaking to get things working through a moderately ORM-agnostic repository interface. No seamless caching yet-that’s slated for v2.

Non-technical factors:

NHibernate was an industry leader, was fairly mature, had been around a few years (and a few MORE years if you counted Hibernate) and a team member (me) had experience using it in a high-profile production environment. No paid support available to speak of (not counting unknown companies here) but a truly responsive, helpful community with a product that is in active development… but then, NO backing company (not even Red Hat these days) … potential of giving fly-by-night appearance to non-techies as a result.

Entity Framework is brand-spanking new. If it were a car, it might still have temporary plates! It’s a 1.0 Microsoft product, with all that implies. Next version slated for 2010. If anything happens, Microsoft’s there for help, or (worst case) to receive a lawsuit. And it’s always easy to justify a Microsoft product.

It was a tough debate, but we ended up going with Entity Framework. Despite agreeing that NHibernate was the better technical solution, the team eventually concluded that having a backing company was extremely valuable for the organization, and that the GUI would be helpful for people coming into the project that were unfamiliar with ORMs.

The next morning, we set about doing some preliminary mapping. (ignore the DDD-related problems with this workflow for now, please)

  • Yeah, that GUI is looking even more inadequate…
  • Generated class and mapping files are THOUSANDS of lines long-this really sucks what with the inadequate GUI
  • IT was REALLY easy to screw up the EF stuff so the gui couldn’t load-easiest way to deal was to redo the whole thing-I think we did that about 5 times that morning.
  • It didn’t seem to deal well with the messy legacy db. Due to the db-first nature of EF, the messiness was going to leak through into our classes…
  • We were going to be on the hook to support this thing-were we ready to do that?

By noon, we’d decided to switch to NHibernate. Cleaner code, clearer classes, and a team member with experience suddenly became a whole lot more compelling.

Working through those mappings has been a valuable, revealing process too. (more on that in a later post)

(Corrected: Thanks to Scott Bellware for the heads-up that even if you’re working on a VB project, it’s still POCO and not POVO, since the C stands for CLR, not C#.)

Broken Windows

Thursday, November 27th, 2008

We all know the broken windows idea, but Jan did a nice, clear write-up of it. such a simple idea, so hard to fight in the day-to-day.

Professional Under Pressure

DDD and Aggregates

Friday, September 26th, 2008

I started reading Eric Evans’ book Domain Driven Design.  (Seemed like one of those foundation books you have to have read if you want to be a certain type of developer)  I decided to give it a go after I got about halfway through the “Domain Driven Design Quickly” pdf – it seemed interesting enough that I wanted to have a go at the real thing.

Anyway, one thing it talks about is Aggregates… basically, a tree of dependent objects that don’t mean anything alone-like line items to an order, as opposed to a customer that is an entity that has meaning by itself.  I guess I haven’t explored things enough yet, but I’m thinking abouton something I’m looking at-I’ve got something like an order, and something like a line item.  There should be no separate repository for the line item.  However, in practice you may need to deal with the line item by itself, for instance the “edit the line item” screen on a website.  In a desktop app, you’d pull out the line item w/ roder, keep that around, and then save when the editing’s done.  However with this web scenatio, you come back from the editing screen and have… some IDs.  Sure, you may have selected the line item from the order… but as the web is stateless, you don’t have your order and order item all ready to update, you’ve got to rebuild that and apply the changes before a saving.  So, you’d pull out that line item from the repository *via the ID*. Or if you prefer, pull out the order via its ID, then iterate through its line items and pick out the relevant line item from the line item collection by ID.. also messy-you preserve the aggregate idea since there’s now no repository for  line items, but you’ve got iteration, and worse, a domain-level usage of picking by ID, which feels like bleed-through.  But you really need the order and the order item, so you can make your changes and then save.  Uh, I guess you can put them in your session, but that just seems even worse than either of the above options due to unreliability.  But maybe that’s me being pessemistic.  anyway, is there a clean way do deal with this?  Or at least a generally agreed-upon lesser evil?

Windsor, for real

Tuesday, September 16th, 2008

So, I finally got an implementation of an IoC Container (Castle Windsor) set up and being used in a production environment…. Based on the whole settings things up for mocking, it became very clear why they were needed!

On a current project, I’d set up and gone though writing tests as I went along.  It was a colleague’s task to write a bunch of integration tests.  (The question of how many full, top-to-bottom integration tests are actually needed is an interesting, but different question… regardless, they are well understood and trusted)  It turns out that all of these interfaces and the tons of newing up required for the dependency injection got to be pretty painful, and what’s worse, confusing and unclear.  Also, as I was refining things, I continued to refactor what was there, so the constructor signatures were changing… messing up AL those integration tests.  I think if he were less nice, he would have said “WHY do you have to make this so confusing??”

Exactly the situation IoC containers were made for.  And I think I got it all set up in about an hour, from download to finish!  Which is a few hours less than I’d expected.  I couldn’t quite get my create down to a single line a) because I was dealing with VB.Net, an irritatingly verbose, hard-to-scan language, but more importantly b) I had to pass in a configured object in to one of my objects, and then pass THAT on to the constructor of object I was really trying to get.  Previously, this chain was hidden among the plethora of newed-up stuff.  Once the container was in place, all I had were these special items, right after each other-this chain of dependencies on the configured object was very clear… the cluttering vanilla dependencies were out of sight.  I consider this a huge, and unexpected benefit.  If I need to change my constructors to break things up more (I have a few places in mind)  then I won’t break these complex integration tests.  My mocked out tests, sure… but they are each restricted in what they touch anyway, so the trouble there is much less.

I know, these were tests, and people often don’t use containers for tests.  However, because of their being integration tests, it felt appropriate.

An interesting point is that this is all going to end up being accessed through a single webservice, so the “live” newing up is only going to be in one place-so less *need* of a container for live.  This is just as well, because another team is doing the maintenance, and this way the unfamiliar stuff isn’t in actual live stuff that’ll could freak them out if something happens with it on live.  Same reason we went with VB…  Anyway, even if we don’t use it on “live” code, Windsor will still save us time.

Of note is really how all these things sort of come together as a package-  DI, mocking, IoC.  You want mocking, you do Dependency Injection, probably Constructor Injection.  You do much of that, and you’ll find yourself wanting something to magic everything up… thus your Inversion of Control Container.  I’d looked at containers a few months back (I’d heard them mentioned a LOT, and thought I should look into them), but I didn’t quite get a grasp of when or why you’d ever use them in practice.  I changed how I worked, and it became obvious.

Moq and mocking on a real project

Tuesday, September 9th, 2008

So, back to blogging… (the whole moving, changing jobs, losing boxes, and generally throwing my life in disarry made expounding on topics an admittedly lesser priority)  in the past week or so, I’ve looked into Moq, mostly on the basis of it being the newer, cleaner, super-awesome mocking framework.  I’d played with Rhino Mocks in the past, so I did have some baseline for comparison.  However, in this case, time and ease was of the essence-I was using this on a real project in which nobody else knew mocking, so quick rampup and ease of explainability were key. Maybe not the best time to pick up an unfamiliar tool, but… uh, no time  like the present and all, I suppose.  I figured since a testing framework is only used on the test side and the production code is not dependent on it (please, don’t split hairs about testing code being production code, I know it sort of is, but that’s not the way I mean) that the risk was a manageable level.  I went out, and set up tests using mocking for all repositories, and for internal utilities.

Moq sure is different from Rhino Mocks.  The basic idea of mock as stub-type thing is preserved, but the actual usage is very different.  In Rhino Mocks, you declare a repository for the mocking framework, get an object from it that fits your interface, and then record a bunch of calls onto it.  Later, you set the mode to play, then run your test code.  Finally, you can verify that all the calls you set up were actually used.  This record/play model takes a bit of time to understand, and to see what it’s for.  In contrast, Moq does away with the special mocking repository, and the who record/replay stuff.  Sounds really easy, right?  Not so fast.  Moq uses lambdas/delegates to set up the calls on the mock object.  Lampdas are a pretty new feature, (thus still new to a lot of people)  and one of the less-easiliy-readable-to-a-newbie- features I’ve come across in .Net.  I’d say they’re up there with regular expressions in terms of initial incomprehensibility.  Worse, I am restricted to implementing using VB.Net on this particular project.  If you thought lambdas were weird with C#, they’re even worse in VB.  I’m a bit worried that I may have introduced a *big scary* thing into this project with using these VB lambdas.  We’ll see if I’ve shot myself in the foot or not here.

Another item of note about this is that is is actually the first time I’ve used mocks in a real project and not just toy projects at home….(old projects sans interfaces could probably be TypeMocked, but not regular mocked without a whole lot of destruction)  It changes the whole project, pushes into the dare I say “modern” way of developing.  This project is essentially greenfield, so there was some oportunity to set things up the way I needed.  This may be obvious, but interfaces really are key.  You use an interface, you can mock.  No interface… well, it’s going to be a whole lot tougher.   The other thing, you have to be able to inject your mocks to use them instead of the regular classes. So… poof, project gets DI.  Once you’ve got things heading that way, your constructors explode.  I have the feeling I’m going to get some pushback on those.  So, if your repositories are mocked, and various utilities are mocked, you end up with a constructor with 8 things in it, and some of those have constructors with a bunch of things… yow!  Which brings in (hopefull) an IOC container to manage the madness.  It’s a waterfall of cause/effect.  Is all that worth it?  Well, you get a lot more flexibility and significantly more granularity in testability.   But what if 95% of developers have no clue about IOC/mocks/DI- these concepts are not only somewhat unknown/advanced, but are genuinely tough to wrap your head around-you’ve just wounded your maintainability through no fault of the technology itself.  Still worth it?  I can’t really say.

DC Alt.Net meeting

Wednesday, May 28th, 2008

OK, this is a bit late, but last week we had the monthly DC Alt.Net meeting. On a bit of a different spin, the topic of the week was Lisp, led by Craig Andera. I hadn’t done any Lisp save for some very, very simplistic stuff back in the college Programming Languages course, so it was really very interesting to get a look at it now, both in that Craig covered much more sophisticated topics that the simple list adds we’d done back then, and that I now have a lot more programming experience. From the strongly-typed, heavily structured background I’m coming from these days, Lisp struck me as fascinatingly different; in regards to my recent experiences, I have to say the mindset was significantly more like Python than anything else I’ve worked with in a long time. Actually, the similarities are convincing me that I should make a serious effort to achieve a pretty sophisticated understanding of at least one of the dynamic languages (Python, Lisp, Ruby, etc) so I have that mental model in my toolbox. Sometimes a different way of thinking about a problem results in finding an answer, but there’s a bonus of a more directly applicable usage in that C# is beginning to borrow some dynamic language features such as lambdas; and the better I “get” dynamic languages, the more I’ll see how and when to appropriately use those new features.

Mini programming exercises

Wednesday, May 14th, 2008

For the past few days, I’ve been practicing writing up small programs. By that I mean small, self-contained programs made up of a few classes, maybe in a single file, with a main method so it can be run as a console app, things that can be whipped up quickly. As I’ve pretty exclusively been working on adding to and modifying a single huge app over the past year and a half, this is pretty different. For one thing, it’s been interesting figuring out the minimum amount is to get a working program, accompanied by unit tests. No Asp.Net, no “Page”, no “Monorail”, no “Enterprise Architecture”, just a bare little program that calculates or solves something. I know it may sound weird to command-line scripters, but this often isn’t done in the web world, particularly the Microsoft web world. Sure, I did this sort of thing in C++ back in school, but I haven’t done it in C# and as I’ve been focused on web, I really did everything from a browser UI perspective, with all the overhead that requires . I’m out of practice, and it’s a bit embarrassing. For the first one, I literally sat there for a bit thinking “how does one go about doing this?” sigh… well, at least this is one lack in my tools at hand I’ll have fixed.

Code Camp!

Sunday, April 13th, 2008

Yesterday, I attended my first Code camp.  I thought it was great! Yes, semesters of lectures in college was a bit tiring, but now, I find I’m hungry for them, especially when it’s just a day. I work with some smart, nice people, but as I’m pretty much on my own in my technical area, I don’t really have any real mentors, and so learning has been kind of a do-it-yourself project. So these sort of events are doubly valuable.

I attended “A Gentle Introduction to Mocking” taught by Scott Allen, which was pretty good-I’ve done some experimentation on my own, so I was ready to hear more. And I really don’t have a C# mentor at work, so seeing someone else do it, and *how* they went though was really informative. Sometimes you pick up little things that they do as a matter of course that you just didn’t catch when walking through examples on your own. And there was a discussion on when to use mocks vs. stubs, which I found interesting. I also had some revelation about my code base at work. There are certain parts of the code base that I’ve never been sure of how to test, or even if it was possible, because they jump off to NH calls a lot. Amusingly, I was also unsure of when one would use DI, or an IoC container. At this talk I suddenly figured out that the way to test those classes is that LOTS of stuff that I hadn’t even considered a problem creating in place needs to be inserted with constructor injection, enough so that it would actually be pretty ridiculous to do by hand. and so, I apparently need a container.

I had originally planned to attend Jay Flowers’ talk on TDD, but as he couldn’t make it, Kevin Jones kinds stepped in for a review of C# 3.0 features. He was actually pretty negative about a fair number of them, and I have to say after reviewing them, I am a little skeptical about some of them as well. The “var” feature in particular seems a bit dubious to me. I mean, we’re dealing with a strongly-typed language here. Introducing something like that feels like inviting in the craziness of vbscript. Maybe I’m wrong, but I feel like opening that door is questionable. I mean it works for Ruby and Python, but but those languages work on the basis of trust-it’s a different philosophy, and I wonder whether mixing in duck typing (though once you assign, it’s actually strongly typed, so it’s hidden typing, not true duck typing as I understand it, at least) to a strongly typed language is really a good idea.

Next was Constructive Code reviews. I was actually hoping for a little more meat in terms of how to approach the code, what things to think about, possibly something involving walking through it with code snippets. It was more a review of the different levels of code review from desk check to a full formal process. Still informative, but maybe not as interesting for me as what I was envsioning.

Next, Michael Podwysocki reviewed Dependency Injection and Inversion of Control. Again, I’d done some review of this on my own, but it was great seeing someone else explain the idea, and then walk through how to actually do it. The lecture took on a lot of extra meaning since I had earlier seen how I could apply it to my current project (whether I actually will be able to reorganize things is a separate manner, but at least I see an application for DI) I’m looking forward to him putting his code up, so I can more closely go over what we did in the class. It was also interesting hearing about other frameworks. I’d also heard about Windsor quite a bit on Alt.Net, and heard mention of Unity and StructureMap and Spring, but hadn’t known there were many more than that. Anyway, very useful.

Lastly, I attended a talk on LINQ To SQL in an N-Tiered Application. I’m still mulling over the level of usefullness of Linq to SQL when there’s NHibernate which is so full-featured. However, the Linq syntax itself is very interesting, particularly as it’s compiled and understood by Intellisense, etc. If it was brought in to nHibernate, it could be a *very* nice third querying option to complement HQL and the criteria interface.

Afterwards, they gave away some swag. Yeah, I can’t complain how I did… got a copy of Vista. Could be very nice to set up for Parallels on a future Mac purchase? Then, some attendees headed over to a next door bar. As usual, some of the most value in the tech events comes from the conversations. Interesting, smart people. Almost enough to make me reconsider my opinion of the average .Net developer… but then I remembered that anyone who cares enough to use their own weekend time to go to a code camp is quite a bit different from the typical 80% of the developer population, so I was not dealing with a good cross section. heh.

MonoRail is rolling

Monday, April 7th, 2008

Got MonoRail set up on SharpShop, and got a Product List page working with it.  I haven’t done too much thus far,  but I’ve gotten a taste.  First off, it seemed like much more of a pain to set it up than turbogears… It might be because tubogears might be more mature, but it seemed a lot more one-command-and-your-stuff is set-up.  With MonoRail, I spent a fair amount of time futzing with the web.config, copying in a variety of dlls, wondering why I was getting page not found messages, etc.  It probably would have been better if I’d been using VS2005 and used their startup thing, but requiring a costly tool to get a decent setup experience seems lame.

Anyway, after much copying, and comparing of configuration, and staring that their Getting Started project I finally got SharpShop set up.  At that point, it really came to me how different this was going to be.  No Page_Load, the usual starting place.  No Page at all, actually, and some sort of scripting language with a for loop seems to be the way to handle repeater tasks and such.  I’m a little uncomfortable with this.  I know some people don’t like the page model, but if you declare “no <%” in the aspx pages you kind of force people to code in the code-behind (overall, good).  This monorail style is maybe a little less magic in the regard of binding and repeaters, but compensates by having some amount of logic in the view page.   Truthfully, I’m not sold yet. I’ve worked on some horrific ColdFusion, as well as classic ASP, and even Perl, and having logic strewn all over the views is a common, massive problem in terms of readability and maintainability.  I worry this could be a slippery slope of allowing people to feel it’s OK again to code right in the view.  I sure as heck don’t want THAT. Maybe the solution is to hire people whose coding judgment you fully trust, and not hire developers that are just waiting and hoping to go back to the bad old days of spaghetti code, but I don’t have that luxury.  (though wow, what a perk that would be)

I’m going to dive further into MonoRail, and see how it deals with a variety of common tasks, and compare that to the usual .Net way.  The page model and all of the goodies it includes are a pretty big selling point of ASP.Net, so I’m curious to see if rails-style development on the platform proves to be worth what you’re giving up.

Maybe a PythonShop #2 is in the works…?

Monday, March 17th, 2008

Looks like IronPython is not only steps away from their 2.0 version, but is python compliant enough that Django runs. Plus, you get to use .Net stuff like Silverlight, which apparently provides some nice UI functionality. This could be interesting… As for the article title, well sure, I understand the sentiment, but the truth is, Microsoft actually played nice while developing the .Net CLR. So guys, only hate when hating is warranted, alright? Anyway, full article here:

Django Now Plays the Dark Side