Yet another reason to avoid the Service Locator anti-pattern is that it violates the principles of Object-Oriented Design.
Service Locator violates SOLID
Yet another reason to avoid the Service Locator anti-pattern is that it violates the principles of Object-Oriented Design. Years ago, I wrote an article about Service Locator. Regular readers of this blog may already know that I consider Service Locator an anti-pattern. That hasn't changed, ...
6 plus ones
Shared publicly•View activity
View 12 previous comments
- that's one of the valid use cases I was talking about. It's necessary and proper there.May 15, 2014
- Here's my response, in case anyone is interested.
http://dotnetdom.blogspot.com/2014/05/service-locators-and-interface.html?m=1May 15, 2014
- Both AutoMapper and EF suffer from the exact same problems, which are one of the reasons I never use them.
AutoMapper could hypothetically be 'saved' by defining an API as
public interface IMapper<TSource, TDestination>
TDestination Map(TSource source);
That doesn't have the same problems because the consumer would typically depend on a specific IMapper, with bound types (e.g. IMapper<Foo, Bar>).
This is reminiscent of this discussion: http://blog.ploeh.dk/2010/11/01/PatternRecognitionAbstractFactoryorServiceLocator
See also the discussion here that I have withMay 16, 2014
- Great write-up! I'd like to share a link on Twitter, but would like to give proper attribution. Do you have a Twitter account?
Regarding blog software, I'm using Jekyll hosted on GitHub Pages. It's not perfect, but fits my criteria fairly well... Apart from that, I don't have any recommendations; it's been a while since I last researched that market.May 16, 2014
- I never tweet, but I'm @j2jensen there.May 16, 2014
- That's OK, you don't have to tweet to get attribution :)May 16, 2014