One of the patterns I follow a lot is creating enumerations in my code for certain reference data. I usually have tables in my SQL database to back up this data, essentially just to give myself the benefit of referential integrity. But it’s a pain to refer to data based on an arbitrary ID in the database, so enumerations are a way to ensure my code isn’t littered with “magic numbers.”
Enumerations by themselves are powerful, but pretty plain. Since 95% of my development work is in ASP.NET MVC these days, I wanted an easy way to render the options an enumeration provides as a drop-down or radio button list. I could do this manually, and it’s not a lot of code, but I felt like there needed to be an easier, more generic way to handle things.
So this year was the second year, now, that I’ve attended the St. Louis Day of .NET conference. Last year was fairly decent. There were a few good talks, but you can’t expect perfection from a small, regional conference that doesn’t have the draw or influence of something larger (like MIX or PDC). Fair enough. This year, however, will be the last time I attend this conference, and it all boils down to this:
Apparently it’s my fault. Apparently I didn’t read some fine print somewhere that says that the STLDODN organizers were going to give my email address to every vendor that sponsored this event so they could flood my inbox with sales pitches and bullshit. Never mind the fact that this year’s conference was even more mediocre than last year’s. Never mind the fact that the keynote was on Visual Studio LightSwitch – a product that Microsoft is pushing on business users to somehow make my job obsolete. Never mind the fact that some of my co-workers are junior level and/or interns, and they couldn’t get into the jumpstart classes because they decided to put them in undersized rooms. Never mind the fact that advanced content is glaringly absent.
There is a lot wrong with this conference, but the biggest problem of all is that now my work email address is being spammed by the conference vendors and sponsors. What the hell? I thought you guys had more integrity. I thought—of all people—my fellow programmers would hate spam at least as much as I do. I guess I assumed too much. Goodbye St. Louis Day of .NET, and good riddance. I will not be back next year.
Well it’s been a few months since the last release, and I decided it was time to get cracking. I’m sorry for the delay, but I hope you’ll agree that it was worth the wait. So without further adieu, let’s go over the new stuff!
So one of the things a lot of people have been asking for is a version of ActionMailer.Net that works without a dependency on ASP.NET MVC. It took me a while to come up with a strategy for doing this, but I think I’ve covered all the bases. That said, I had to move things around. So here’s how the project is laid out now:
- ActionMailer.Net – This project contains generic code that can be applied to either the MVC or Standalone versions of ActionMailer.Net. This DLL is referenced by the other two projects as sort of a “Core” set of functionality.
- ActionMailer.Net.Mvc (Nuget: ActionMailer) – All the MVC-specific stuff has been moved into this project. This means that MailerBase, EmailResult, and all the Html/Url helpers live in this project. In most cases, all you’ll have to do is change your “using” statement to this new namespace, and your existing code should work just like it has been.
- ActionMailer.Net.Standalone (Nuget: ActionMailer.Standalone) – This project contains a standalone version of the ActionMailer.Net email rendering engine. Right now we only support Razor views through two new classes: RazorMailerBase and RazorEmailResult. I’ve decided to use the RazorEngine project to power this system. This engine supports models in the same way MVC does, but some other features (i.e.: layouts) have not been implemented, yet. This support is still pretty basic, but it should be enough to do most things fairly well.
Over the past few days I’ve been working on an application here at work that will be sending emails pretty heavily. Up until now, my usual plan was to just write a couple of helper methods that I could call. These helper methods would undoubtedly use StringBuilder to do most of the grunt work, happily formatting my emails. The problem with this approach, however, should be obvious. There are tons of templates hard coded in C# with string literals all over the place… YUCK!
So I took a step back. I realized that the Rails framework really has this nailed. Through the awesome ActionMailer library within Rails, you can use the built-in template engines to generate emails almost exactly like you would generate a view. This leads to very small helper methods, and it’s just so darn clean. I think the MVC community could use a cool library like this, so I decided to write one.
In a previous post regarding the ISession from Rob Conery, a commenter asked about our implementation of ISession with regards to EF4. Rather than send him the specific code, I figured I’d make another blog post to outline exactly how we use it here at work.
Basically, each of our projects has a “Data” layer where we store everything needed to communicate with the database. This is also where the ISession interface lives, so it’s easy to provide the implementation. There is one caveat, however, because we need to provide a generic EF4 implementation that can work with any data context. In our projects, sometimes we need to speak with multiple databases, and then it becomes just a matter of plugging the right entity collection into our implementation. Here’s what the code looks like: