search

jwodicka / Mural-legacy

A social chat server with MU*-inspired features, supporting multiple characters per account and pass-through access to MU*s running on other servers and codebases.
4 stars 0 forks source link

Use an Inversion of Control container to provide object dependencies #3

Open jwodicka opened 13 years ago

jwodicka commented 13 years ago

A number of the objects in the system currently construct other objects to help - particularly, connections construct parts of the message pipeline, and things that need data construct the relevant providers to go out and get it from the DB.

While much of the code is already abstracted into interfaces with concrete instances, and does a decent job with manual dependency injection, we need to improve the dependency injection, and wrap it all in an IoC container to give us a point from which to manage it.

I'm currently looking at Ninject - http://ninject.org/ - as a way of doing that, and some TODOs littering the code make reference to it - but if you have an argument for another IoC container, we can have that discussion.

bishoprook commented 13 years ago

I've been happy with both Ninject and Spring in the past. I think Ninject is a bit more convention-over-configuration, so it might be cleaner.

Another question is whether to use constructor injection or property injection. I lean toward property injection simply because it's the coding standard at work (which bled through from the coding practices of the NServiceBus project), so I'm more used to it, but constructor injection might be a bit more technically correct. You can ensure that dependencies are never null, and the dependencies can be private readonly fields rather than public settable properties.

jwodicka commented 13 years ago

I think most of the dependencies we're working with make more sense as constructor-injected dependencies. For one thing, they do tend to only have private meaning to the class that requires them - nobody needs to be able to ask the login parser what AccountStore it's using to service login requests; it just needs to get a hold of some provider of account information.

On Mon, Aug 1, 2011 at 11:04 AM, bishoprook < reply@reply.github.com>wrote:

I've been happy with both Ninject and Spring in the past. I think Ninject is a bit more convention-over-configuration, so it might be cleaner.

Another question is whether to use constructor injection or property injection. I lean toward property injection simply because it's the coding standard at work (which bled through from the coding practices of the NServiceBus project), so I'm more used to it, but constructor injection might be a bit more technically correct. You can ensure that dependencies are never null, and the dependencies can be private readonly fields rather than public settable properties.

Reply to this email directly or view it on GitHub: https://github.com/jwodicka/Mural/issues/3#issuecomment-1702532

bishoprook commented 13 years ago

Sounds good to me!