Hello, LWhisper, you wrote: LW> In this connection a question - what to do? LW> is certain applications which, being torn through set of abstraction layers, all leaves more deeply in a jungle of internal-assemblages and in passing acquires parameters-dependences, to the lower points of the falling coming to that to 28 arguments in the designer of the next class without which he cannot live. One of OOP major principles: the bulb twists itself in a lamp itself. LW> here both Id sessions, and Id the current task, and a user id, and and still what the hell, on the person awful, inside. As the component doing real operation, depends on identifiers and journalizing (many here very narrowly understand terms, therefore I specify: it is sacral in Russian)? To fulfill operation, the instruction, instead of log is necessary - it is logical? Operation depends on the instruction, log from an operation state. Dependence in your application other - log depends on components, instead of they from it. If it to realize, it becomes easier to untangle a ball of dependences. How to log to learn about a current state of components and to replenish itself? How to components to inform on the state in the independent image? NET there is a mechanism of events - he solves both questions a simple method. It is not necessary to ignore it. LW> It would be desirable to throw out it in any easily accessible (both in respect of the code, and in respect of performance) a context with which it will be easy to communicate. LW> for given by that context the DB, thanks to that it only one access is carried out through (sometime it is mandatory shoots - _-) appears. LW> And here for all remaining it misses, and these dependences per aspera ad astra are pulled. LW> we Take, for an example, . LW> application Here is started and quickly starts to write a broad gull. The broad gull name goes down in arguments a command of a line. LW> Okej, is difficult to refuse it (though and it is possible) but while it is tolerant. LW> there is an authentification of the user. Now the broad gull is written already to the directory of this hapless user. LW> the user executes some command, the broad gull is written all to the same folder, but already in a file with a name of an executed command. LW> the command begins and works with different computers in a network. Each task starts to write a broad gull to a file with a name mentioned above a command + computer name. This listing of events to which the log should react (). It is necessary to think over the mechanism of the publication of events and a subscription to them. Default events.NET, the homebrew manager of events is already details. LW> in process, we start to use more low-level interfaces which too write a broad gull and not at all do not know anything neither about users, nor about commands, about hosts. But thus too want to write to a broad gull a current state and errors, leaving on if the grid blinked, but still there is a chance to receive the response from the remote machine. And to write that broad gulls it is necessary in the same files with a name of a command, a host, in a folder of the user. There are ThreadLocal-collections through which transit all calls. The same principle, log receives entering events and itself solves where they will be saved. All smart logic of crushing of log will be concentrated in one place, any contexts. LW> but low-level components too not a bast and besides top-level, pull asynchronous methods on lower which are at all fulfilled in a casual flow from a pool and in turn too pull even more low-level components which still want to write broad gulls to the same files, as far their component. So it is necessary to drag through all layers and to register it in a static ThreadLocal-collection from the previous series. Components should publish events, to log them to listen. LW> some time I smother torment thoughts about Dependeny Injection. But in the company already there was an unsuccessful experience of implementation of this piece (about which (oh) I neither a dream, nor spirit), ended with cutting out of this with a considerable quantity . In general, did not get accustomed, yes it and is clear - lifetime and the order of initialization of objects were misunderstood from a word absolutely, and frequently objects which they did not ask were returned to people, and have been registered at all do not understand whom, when and for what purpose. In general, all is bad, and besides because of unreasoned architecture, on a knee that though somehow worked in style write-only. Implementation of dependences - a short-term stage at program start. It here it is simple at anything.