Tim Barcz - All Comments

re: Real Life Single Responsibility Principle

Tim Barcz — Wed, 07 Jan 2009 14:45:30 GMT

@Dave

Good point about DRY...you didn't get a chance to see the actual concrete implementations but they adhere to DRY. See my comment reply above to "Scott" to understand. Each piece of code that "sends" an email is unique for this application.

re: Real Life Single Responsibility Principle

Tim Barcz — Wed, 07 Jan 2009 14:44:27 GMT

@Scott

The strategies are rather simplistic at this point. The Queued service uses a database table and there is a job running on an interval which looks at this table to see what needs to get send.

The real time email sends directly through SMTP.

We have other solutions using MSMQ that we'd like to go to but it's just not justifiable right now in terms of setup and cost when what we have works and works well.

re: Real Life Single Responsibility Principle

dave thieben — Wed, 07 Jan 2009 14:18:25 GMT

Nice post. However, I would remind people to also adhere to the DRY principle, in the chance that you have email-sending-related code that is the same in all three classes.

re: Real Life Single Responsibility Principle

Scott — Wed, 07 Jan 2009 13:29:11 GMT

What happens when you have a second high priority message to send before the previous high priority message send is complete? Don't the high priority messages need to queue up also?

Not to disagree with how you implemented the solution you decided upon but rather to suggest another solution; Did you consider have multiple queues and a class to pull from the queues based on priority? Ie. a low priority and high priority queue. Many MTA's use this approach as it is conceivable that many high priority emails will need to be sent at any given time. At that point, you need to work through all the high priority items before returning to normal or low priority items in the simplest approach. Others might do a biased round robin H-H-N-H-H-N-H-H-L-H-H-N ..... kind of thing.

re: Real Life Single Responsibility Principle

Tim Barcz — Tue, 06 Jan 2009 14:49:37 GMT

@Lance

Tuna is correct, everything get's stitched together through our use of Windsor (IoC container). I recognize that this may create some confusion when people say "just use an IoC container" and so I hope to get some concrete examples out there sometime

Dew Drop - January 6, 2009 | Alvin Ashcraft's Morning Dew

Dew Drop - January 6, 2009 | Alvin Ashcraft's Morning Dew — Tue, 06 Jan 2009 14:27:55 GMT

Pingback from Dew Drop - January 6, 2009 | Alvin Ashcraft's Morning Dew

Reflective Perspective - Chris Alcock » The Morning Brew #258

Reflective Perspective - Chris Alcock » The Morning Brew #258 — Tue, 06 Jan 2009 08:52:58 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #258

re: Real Life Single Responsibility Principle

Tuna Toksoz — Mon, 05 Jan 2009 23:23:39 GMT

@Lance probably IoC would do that, you can configure a specific class to be resolved.

re: Real Life Single Responsibility Principle

Lance — Mon, 05 Jan 2009 22:50:58 GMT

I'm talking about how consumers would use this class. How would they know to use one mail service or the other? If the only difference is the mail priority, I'm not sure why the Queued or Real time services would even need to be exposed to the client since sending it to the PriorityMailBasedService would take care of sending the email without the client needing to worry about the priority which seems to be more agree more with the Law of Demeter. Forgive me if I am being dense.

re: Real Life Single Responsibility Principle

Tim Barcz — Mon, 05 Jan 2009 22:35:27 GMT

@Lance

The if statement is how I know which one to use.

Three classes, three different responsibilities:

1. QueuedEmailService - queue the message for some other processing

2. RealTimeEmailService - send the mail right now

3. PriorityBasedEmailService - figure out which service to use.

Does that clear it up at all? Let me know and I'll seek to clarify further.

re: Real Life Single Responsibility Principle

SuperJason — Mon, 05 Jan 2009 22:32:57 GMT

Ok, I was just trying to clarify what you were saying.

Personally, I avoid SendAsync as well.

re: Real Life Single Responsibility Principle

Lance — Mon, 05 Jan 2009 22:31:59 GMT

You don't show how these classes are being used. When do you know whether to use Queued or Realtime if you don't use an if statement? There's an if statement in the PriorityBasedEmailService which seems like more conditions could be added on later.

re: Real Life Single Responsibility Principle

Lee Carter — Mon, 05 Jan 2009 22:07:23 GMT

First, thanks for re-reminding me of the RDD concepts: Know, Do, Decide - it's a great, and useful, distinction.

Second, I found the "now you might be thinking..." comments kind of annoying, until I realized that, yes, that's exactly what I was thinking. It was useful to get called on it. So...thanks for that, too.

re: Real Life Single Responsibility Principle

Tim Barcz — Mon, 05 Jan 2009 21:48:04 GMT

@SuperJason,

Catching issues around mail and failing is harder with SendAsyn from my experience. When it's a blocking call and it fails, you know.

re: Real Life Single Responsibility Principle

SuperJason — Mon, 05 Jan 2009 21:43:36 GMT

"(Note to BCL junkies: yes I know there is a SendAsync method). There are a few instances in our application where we want email to be sent right away and not queued."

Are you suggesting that SendAsync doesn't send the email immediately? Not a big deal, but it works the same as "Send", but the call itself is asynchronous.