E-mailing in MVC, the final frontier...
Posted: Sun Dec 07, 2008 2:26 am
I have slowly but surely found the optimal placement of every aspect of my application logic within MVC (optimal to my preferences anyway). There have been many obstacles that I've had a hard time finding a place I found suitable for, for instance,
I struggled with validation for quite some time, as evidenced by the 900 posts on this board I have posted about validation, and finally ended up writing (with the help of arborint and a few others) a rockin' awesome filter/validation chaining library that solves the problem really elegantly. I am completely satisfied with how I handle forms now... FINALLY!
I then struggled with a constant tendency to design really fat controllers, and almost non-existent models. I didn't even realize I was doing it until I started working with other developers and found that their controllers had almost no code, the majority of logic lying in their models. I have since rethought MVC and realized that I was interpreting the purpose of the controller completely wrong. So, I have finally adopted a more fat-model skinny controller approach that has worked out great.
Now it appears I'm finally approaching the final frontier. This is an area I have never had a solution I liked, instead relying on "good enough" solutions for e-mailing in MVC. E-mailing is an area that reminds me somewhat of form-handling. Like form-handling, e-mailing may involve several or all tiers of MVC. It generally requires at least one model (user, product, etc), and it needs a view (the e-mail template). What I'm unsure about is how to wrap these two together. A controller?
The question of how to deal with E-mailing becomes even more hard for me to answer when it comes to applications that send a lot of e-mail notifications and the like. In these types of applications, it just seems impractical to put this code in the controller, creating swift objects over and over. There has to be a better way.
Where do you put e-mail notification code? Model? Controller? Some kind of e-mailer factory class? I've considered all of these and nothing seems right.
I struggled with validation for quite some time, as evidenced by the 900 posts on this board I have posted about validation, and finally ended up writing (with the help of arborint and a few others) a rockin' awesome filter/validation chaining library that solves the problem really elegantly. I am completely satisfied with how I handle forms now... FINALLY!
I then struggled with a constant tendency to design really fat controllers, and almost non-existent models. I didn't even realize I was doing it until I started working with other developers and found that their controllers had almost no code, the majority of logic lying in their models. I have since rethought MVC and realized that I was interpreting the purpose of the controller completely wrong. So, I have finally adopted a more fat-model skinny controller approach that has worked out great.
Now it appears I'm finally approaching the final frontier. This is an area I have never had a solution I liked, instead relying on "good enough" solutions for e-mailing in MVC. E-mailing is an area that reminds me somewhat of form-handling. Like form-handling, e-mailing may involve several or all tiers of MVC. It generally requires at least one model (user, product, etc), and it needs a view (the e-mail template). What I'm unsure about is how to wrap these two together. A controller?
The question of how to deal with E-mailing becomes even more hard for me to answer when it comes to applications that send a lot of e-mail notifications and the like. In these types of applications, it just seems impractical to put this code in the controller, creating swift objects over and over. There has to be a better way.
Where do you put e-mail notification code? Model? Controller? Some kind of e-mailer factory class? I've considered all of these and nothing seems right.