This post will not be about Subversion.
Something Anderson talked about recently was how the Provider Pattern wasn't just for ASP.NET. He offered up a good example, but I thought I would expand on it a bit.
Something I've had great experience with is an application that I like to call a "Message Massager" or a "Message Munger" (pronounced mun-jer). Basically, the program flow is:
- Get input from some entity A
- Munge/Massage the input
- Give the input to entity B
- Get response from B
- Munge/Massage response
- Give the respone to A.
- Lather, rinse, repeat.
When I started, I hadn't really thought a lot about how I could make things easier on myself. I created all sorts of classes and schemas, and it never clicked that I was essentially doing the same thing over and over. After reading his post, I saw several ways I could have made my (and the developer who adopted my applications) life easier.
I won't go into the details of implementing a Provider pattern for this type of application - Anderson laid them out pretty well. Something else that I came across recently, though, might also be of interest. Eric Sink recently offered up an implementation of Map with multicore support in C#. Since most of the messages that I was munging (yes, that's the technical term) were independent of each other, this might have sped up performance quite a bit - several times my applications were dealing with 500-1000 messages per iteration. This is all just speculation, since I don't work on those applications anymore, but it's something I'll have to keep in mind for the next time someone hands me a stack of paper that defines an interface for communicating with some huge system.
2 comments:
Now you made me correct you. But its fine - you just didn't realize my first post was crap. Here's my new one:
Provider Patterned Solutions Explained
It's still crap, but at least it has pictures.
Ah - pictures. Very good. I like that everything is Super-Important.
Post a Comment