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.
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.
One of the ways I like to learn is by watching screencasts. I find that it’s easier for me to retain information. I suppose I’m just a more “visual” learner. In light of this, I’ve decided to record a short screencast introducing some of the basic features of ActionMailer.Net.
I’ve recently released a new version (0.4.1) of this library which adds support for true multi-part messaging and a whole bunch of URL and HTML helpers that you can use in your views. ActionMailer.Net also has a pretty thorough set of unit tests, so feel free to hack around and let me know what you think!
I’d love to make some more of these covering some of the more advanced features in ActionMailer.Net. Any feedback is welcome and appreciated!
P.S. – For those of you that would rather watch the uncompressed video or can’t access YouTube at work, feel free to grab the video here (you’ll need 7-zip to decompress it).
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: