Hello, maxkar, you wrote: M> It is very unsuccessful statement.... The part of things (like the same and transactions) is a context integral part. Therefore everyones just normally look as a context part (and it is not necessary to name them service!) . The context is an OOP-shnyj object with some general behavior. It not "service registry" in the standard sense. The dial-up of given services at it also is known. Well so it is even more unsuccessful statement, at least for . Because instead of classical "there is no real scenario of usage - all theoretical researches go wood" we pass to " to a real problem, but on a canon (tm)". Last - is faster to , there the such is very much approved. Why on the real scenario ? So your councils do not approach. The context does not have behavior, it on determination (we want to give other dial-up of services - we substitute a context) and can give as dependences, and difinienda in . Disorder otherwise begins: a part we transfer through a context, a part - through DI. Faugh-faugh-faugh M> Well here all is banal. Here directly to the given code refactoring "Tell, Don't ask" is applied. Also it turns out mentioned Well so it angrily in the cleanest type. Instead of explicit sharing (all initialization - in one method) at us turns out a mash from * Actually implementations * Wrappers SmartConfirmationService, * Substituted factory which will select specific implementation. Not to do copy SmartConfirmationService for other method, say, for GetAdvancedConfirmationService Here this approach "we do not look at a real problem, we can in patterns" is initially vicious, since it leads to wild recomplication of the code out of the blue. On the same example I will explain. Besides a heaping of types we have one more jamb: we prolong lifetime of dependences - in original code Consumer was necessary only for obtaining of specific implementation, it is possible to transfer only implementation further. At you consumer it is necessary to drag further. , we remember consumer through designer SmartConfirmationService. All? : at us a bug: consumer if it to change not that service suddenly comes. , we define the necessary service at once, in the designer... And we appeared in an idiotic situation: the recomplicated code which as a matter of fact hides call GetConfirmationService in separate object. Hurt architecture. All the same problem of mongooses in a mail box the Author: Sinix Date: 01.06.14, . M> And here to get interfaces in a place "implementation insertions" - good. Well, there will be many small interfaces, will be Interface Segregation. Well, that's it about it I also spoke. Accurately to think over API - is not present, the "correct" code wrappers in a place, even breaking architecture - yes. Not, a taste question certainly, therefore even I will not argue M> And then the syllogism becomes very much. Instead of the further magnification of an amount of parameters, they decrease to one/two primitive values - identifiers of entities. And service learns to walk itself in basis artful requests and to get exactly that is necessary for it. Here such "overflow" of the list of arguments. Here it not simply angrily in the pure state, and rectificate is direct. Without comments, .