NuSoft Framework Background

posted on 03/04/08 at 08:37:50 pm by Joel Ross

Over the past few months, I've talked about the NuSoft Framework quite a bit, but after a twittersation (here, here, here, here, here, and here - Twitter needs threaded conversations!) with Matt Blodgett, I realized I've never really talked about what the motivation was for initially creating the framework. I've touched on it here and there, but nothing that I could point to and say "This is why we made the framework and why we use it over other options."

So let's start with the first - why did we even bother making the framework? There's plenty of other options out there, so why bother? Despite the fact that the framework became publicly available in the second half of 2007, it actually has it's roots at Sagestone back in 2003 or 2004. I started a new project, and it was against an existing database with 200+ tables. At the time, we debated typed datasets versus custom classes. The advantage that typed datasets provided was speed - creating them would be easy. You just imported your database and you were done, right? Yeah, except then you were stuck with the dataset's way of doing things.

So how could we justify using custom objects? Well, the only real way would be if we could quickly create those objects. One option was an O/R mapper, such as NHibernate. We considered a tool like that as others in the office were using them successfully. From my little experience with O/R mappers, it seemed that you still needed to create the objects and the mapping file. So really what you were saving was writing the SQL to persist your entities. Helpful, but that's still 200 classes to code up by hand, plus 200 mappings to create.

Better than all by hand, but not as efficient (from an up front development time) as datasets. As I started looking for easy ways to create the objects, I came across CodeSmith and a template that could create your hbm files. This was interesting, so I pulled down CodeSmith, which was free for generating code at the time. While my intent was to look into NHibernate, I started looking at the samples. Hmm. There was a sample to generate stored procedures for basic CRUD operations. There was a DAL template that worked with those stored procedures. And there was a simple model that got populated by the DAL. All were based on database tables. With a few modifications, that might work.

And so we tried it out. The time to generate all 200 classes was a little more than datasets would have been, but working with objects rather than datasets was much easier and more than made up for any speed advantage datasets had up front.

As I matured as a developer, I realized I wanted my entities to be much smarter than the model I'd been using. I slowly took those original templates and expanded them to be smart objects, tracking their own changes and ensuring they worked together to support transactions. I started looking into the CodeSmith API and figured out how to read relationships and started generating properties based on database relationships - Customer has a collection of Orders, Order has a Customer, etc.

At the same time, others inside of NuSoft (who, by that time, had acquired Sagestone) were doing something similar, but mostly by hand. And they had a base class that had some nice initialization methods for populating the entities. We eventually came together and over the course of a few lunch meetings and a lot of late nights, we came up with an early version of the framework. From there, we rolled it out internally. I gave presentations to both of our main offices and did a virtual meeting to get the word out. There, I laid out some of our core reasons for creating the framework (see, I'm finally getting to the point!).

Looking back at my rollout presentation, most of the reasons I listed were around being more efficient on our projects. From what we observed, there was a lot of variations from project to project, depending on who was in charge of the project. Our goal was to give every project the same basic framework to work against - that when you started a new project, you didn't have to worry about the technical details of saving or deleting objects, but you could focus on the domain problem - what the customer ultimately cares about. As a consulting company, our goal is to keep our bill rates up. One way to not do that is to charge customers to write CRUD code (that's Create, Read, Update, Delete - not cruddy code!). A side effect of this whole thing is that we're able to get new developers up to speed much quicker. First, they don't have to know the low level details to be productive, and second, as they explore the framework more and more, they learn the low level details - and since this is time-tested, they learn to do it correctly. And yes, I understand that "correct" is relative.

Anyway, if I boil our rollout to bullet points, here's the arguments:

  • Use Something. Part of this wasn't about the framework at all. We didn't want to force anything on anyone. We wanted to highlight that you can use it, and if you choose not to, you should have something else you are using. Where we're at in software development, it just doesn't make sense to handcraft repetitive, error-prone code.
  • Not Invented Here. NIH gets a bad rap, some of it deserved. In this case, it might be as well, but the bottom line was this framework was created based on how we'd already been doing things. Across most of the projects in our office, using the framework was a natural migration from what we'd been using - it felt familiar, just a bit more complete. By going with another tool, we'd have to get everyone trained on how this new tool worked, and when new features were needed, we'd be at the mercy of the project developers to add those. With the NuSoft Framework, since the developers were on staff, changes could be made much faster and tailored to suit our needs.
  • CodeSmith Usage. A lot of us had already been using CodeSmith, so creating the framework in CodeSmith was natural. We've considered converting to something else, but haven't seriously considered it because of what CodeSmith gives us. Along that same note, we already had partial templates in CodeSmith that we incorporate into the framework templates.

Notice that none of this answers why to pick it over something else. When we started, SubSonic was still called ActionPack, and when I first looked at it, I didn't care for the fact that it exposed data readers to the UI, which I don't care for. .NetTiers was a lot more bloated than we needed in most cases. LINQ wasn't even on the radar. Just about everything we looked at didn't do what we wanted the way we wanted to do it. Given we were over half way there based on what we already had, it wasn't that hard of a decision to do it ourselves. Add to that having the flexibility to be able to add to it without relying on others or forking from the base, and it wasn't really that hard of a decision.

I realize this does nothing for those starting fresh and wondering why they should choose the NuSoft Framework over something else. SubSonic has come a long way (but still exposes readers to the UI), and LINQ looks promising, even with the problems I've seen with LINQ to SQL. But I think questioning why we even bothered with the framework is a bit naive. It's like asking why there are multiple IoC frameworks out there, and new ones keep coming out. Just because something similar is already there doesn't mean there's not room for a new entry into the field, and, as you can see, we had our reasons for doing it.

I guess it really comes down to preference. Does the NuSoft Framework do things the way you want them to be done, or not? Is it a closer fit than the other options? If so, then it might be for you. If not, well, it certainly doesn't hurt that there's competition out there.

While we don't have a huge external user base, the ones that do are very supportive of our efforts. Internally, I'm constantly hearing about new projects that are using the framework successfully. At a recent internal meeting with 40-50 developers in the room, someone asked how many had used the framework, and just about everyone raised their hands, which completely took me by surprise.

I think that's enough of a rant. If you've used the framework, please feel free to add your thoughts about why you chose it over something else in the comments. If you chose something else, let me know what we're missing. I'd love to get the feedback.

Actually, I forgot the number one reason we made the framework - whenever we met, we got free lunch. I never pass up free lunches!

Tags: | | |

Categories: RCM Technologies