Re: Is IoC containers harmful for DDD?

On Tue, 2 Dec 2014 06:05:31 -0800
"Greg Young [email protected] [domaindrivendesign]"
<[email protected]> wrote:

> I'd be happy for you to put up some examples of dealing with
> application services/command handlers to illustrate the points you
> make. I dislike talking in hypotheticals, code is much easier.
> 
> Cheers,
> 
> Greg
> 

Sure, I agree :)

So for example, a service (with couple of dependencies, just to show
what features container provide)

class MyServiceHandler : IHandler<SomeCommand> {
  private readonly IDataContext DbContext;
  private readonly IMailService MailService;
  private readonly Func<IDataContext> DbContextFactory;
  private readonly IEnumerable<Notifier<SomeCommand>> Listeners;
  public MyServiceHandler(IDataContext dbContext, IMailService
mailService, Func<IDataContext> dbContextFactory,
IEnumerable<Notifier<SomeCommand>> listeners) { ... }

  public void Handle(SomeCommand message) {
   ...
  }
}

So let's use this service as an example. I would like to have my devs
write nothing else except this if they want to handle handling of
SomeCommand. If they understand the language of dependencies - Func,
IEnumerable, it's pretty easy for them to request dependencies in the
context they expect.
So for example, Func<service> in IoC terminology means a new instance
of the service, so if they need to be able to do separate transactions
they can just write

using(var nestedCtx = DbContextFactory())
{
  ...
  nestedCtx.Save(...)
}

If then need to look up multiple implementations for some service by
using IEnumerable<service> they can get all those services resolved
within the current context.
Then don't need to care whether they are inside a Thread context or in
some explicit using context (as descibed above), nor they should.

If dependencies are runtime dependent, this means same class can be
used for several purposes (ex. sometimes it will have 4
Listeners, sometimes 10 - depending on the context).

Of course, I've seen my own devs struggle with IoC (when something is
not working) and even I sometimes need to think hard about why things
are not working as expected, but I would rather push complexity to a
single point of failure, then have it spread through the codebase.

Regards,
Rikard

-- 
Rikard Pavelic
https://dsl-platform.com/
http://templater.info/


------------------------------------
Posted by: Rikard Pavelic <[email protected]>
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/domaindrivendesign/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/