Thursday, November 18, 2010

Pokeball Contact Lenses

The retouching - EBC in Brownfield

vincent-van-gogh-retusche long it took, that I have ventured on this subject. Now, it is as far as the current project situation demands it.
EBC's I want to insert in a brownfield project. The difficulty is the project itself, creating its very "interesting" structure of the EBC's virtually prevented. However, I believe, I can project by using EBC's improved and in the range of infrastructures, respectively, the logging.

exist currently many thousands of lines of code in the project, carry out the logging and therefore "contaminate" the code better or distract from the essentials of the functions. My Plan is to integrate so with the aid of a logging aspect of AOP, then the EBC just technology performs this function. One might think one or the other: "Nonsense, that's not necessary, the traditional approach is still perfectly adequate." I can not in principle oppose it, unless I mention the decoupling between aspect and logging framework or the simplified asynchronous logic. But these are all attributes that have no place in any well-planned software something.

No, seriously, I have to be formulated before the aspect and the logging process as the EBC's, so I can take advantage of the EBC. This way, I may reach something else: concurrency of the application infrastructure. Well let's see where that leads.

current condition

To illustrate here is a representation of the actual condition of any data access method:

Daten laden

  • , data is read
    • If an error occurs, an error message created and sent to a logger sent him wegschreibt
  • data into DTO's mapped and returned

target state at the point of step "Handle Exception" I would like to take the famous try-catch block, an aspect Use of performing the same task, but the code does not become contaminated.

Handle Exception Log is the aspect that is used in the application and in case of an exception, sends the message to the logger. This communication should be done asynchronously, so that the logging, the application does not block or slow down.

history to solve

In the beginning the statement, "AOP for logging. This is what I wanted to implement with PostSharp because I herumhantiere so many years. But then came the sobering: the aspects I can instantiate on any circuit board and wiring. This meant that I had a little trip to SNAP made because hereby issues and instances in one and the same DI containers are treated ... look for yourself:

solution Test 1: post sharp point, and the board

PostSharp aspect + EBC output
class
  1. [ Serializable ]
  2. public Log : OnMethodBoundaryAspect , ILogAspect
  3. {
  4. public override void OnException ( MethodExecutionArgs args)
  5.     {
  6.         OutExceptionLog( new ExeptionLogMessage (args.Exception)
  7.                                  {
  8.                                      Method = args.Method.Name
  9.                                  });
  10. }
  11. public Action \u0026lt; ILogMessage > OutExceptionLog
  12. {
  13. get ; set;}
  14. }


Logger as EBC
  1. public class Logger : ILogger
  2. {
  3. public void InLogMessage ( ILogMessage logMessage) {
  4. System.Diagnostics. Debug WriteLine (logMessage.ToString ());.
  5. }}

Wiring
  1. object factory Configure (x => x.For \u0026lt;. ILogger > (). Use \u0026lt; logger >());
  2. object factory . Configure (x => x.For \u0026lt; ILogAspect > (). Use \u0026lt; Log >());
  3. ILogger logger = object factory . GetInstance \u0026lt; ILogger > ();
  4. ILogAspect logaspect = object factory GetInstance \u0026lt; ILogAspect > ();.
  5. logaspect.OutExceptionLog = _logger.InLogMessage;

sees all this totally simply, it is. But as is so often the devil is in detail, because the issue is controlled by post sharp and is not for this type of wiring. So if I get a new copy for the purpose of wiring, I do not really connect the pins of the components that actually works, but rather just a new instance. The aspect that is sending his message in the electric Nirvana.

solution Test 2: SNAP and StructureMap

This attempt failed because of the requirement to work at Brown Field and the fact that I can not to the actual instances of the aspects of access and realize that the wiring.

Solution Review

In both cases I the working logger instance is not with the wiring, because I have no control over the Instanziierungszeitpunkt.

One solution would be a global event listener - to this idea I would have my brain with soap - which collects the events of the aspects and processes. This is not EBC, which is unexpected behavior that I think is not clean code. Therefore, something her other: Static Out pins. They are very easy to implement and also more understandable.
But what hurts at the thought? True, the keyword "static". I have just too many bad experiences with public static methods or fields made. Only in this case there seems to be nothing better, right?

explanation - euphemism

So if I have a static field on the aspect and thus create the EBC character of a component, then this may not be that bad. Moreover, this also fits into the concept of infrastructure. Logging is part of the infrastructure, is a peculiar concern and thus can exist as a large whole in the application. Almost as a global component that receives the messages from all sides and processed.

Now, if someone has a bitter taste in the mouth, should leave a comment on this topic because I too am using the static field not so lucky and maybe we can find a better way.

The solution

I have now decided once for solving a number and change only the scope of the pins out of "public action" to "public static Action". This way I can handle wiring and the news.

aspect with static Pin Out
  1. [ Serializable] public
  2. class Log : OnMethodBoundaryAspect
  3. {
  4.          public override void OnException( MethodExecutionArgs args)
  5.         {
  6.             OutExceptionLog( new ExeptionLogMessage (args.Exception)
  7.                                      {
  8.                                          Method = args.Method.Name
  9.                                      });
  10.         }
  11.  
  12.          public static Action < ILogMessage > OutExceptionLog
  13.         {
  14.              get ; set ;
  15.         }
  16.     }


Verdrahten
  1. ObjectFactory .Configure( x => x.For< ILogger >().Use< Logger >());
  2.  
  3. ILogger logger = ObjectFactory .GetInstance< ILogger >();
  4.  
  5. Log .OutExceptionLog = _logger.InLogMessage;

This looks really been made easy. How does this make in practice, I will now watch for now.

Addendum

I mentioned at the top or the asynchronous processing. I'm building also just place as you would like Ralf Westphal described it in his blog for Asynchronous communication with EBC's .
Whether I have been using Rx, I'll also see. Today, I would first like to establish the basic framework.

~ Jan

0 comments:

Post a Comment