A pattern for transforming and combining multiple data types behind a simple interface

Question

I'm having difficulty conceptualizing a sane abstraction for a small event logging framework, and haven't come across anything comparable in the wild that would apply here.

Overview: our web application needs to log events from the server side. The event data is json encoded to written to a flat file. An event might be a page view, a signup, an error condition, etc.

All events would contain a set of core data, like web request information and session state. Any event should be able to define additional data to be recorded.

Ideally, the interface to fire an event would be extremely minimal. Event definitions and data requirements should be defined in a single configuration file. Data validation and data transformations should be hidden behind this configuration file. In other words, the interface to log an event should require only an event name and the data structures to be transformed and recorded in the event.

My original thinking was that a single data structure would be mapped to a single function whose responsibility is to transform the data structure into a dictionary that would eventually be merged into the final event object, then json encoded and written to the file. I'm referring to these as "composer" functions. In Django terms, something in the configuration file would map, for example, the HTTP request object that's passed to the view to a "request_composer" function. The function would construct a dictionary of data that's pulled out of that request object. The event that's emitted from the view would be required to pass in that "request" object.

I suppose my question is if there is a pattern or abstraction that I've overlooked that cleanly transforms arbitrary data structures and merges them into a final data structure. I feel like this "single data type maps to a single transformation function" is a little kludgy and inelegant. It also breaks down when it makes sense for a single transformer to accept more than one argument.

Answer 1

That sounds a lot like Facade (simple interface to complex implementation), possibly combined with Strategy (switch between several concrete implementations of a process at runtime or during configuration/startup) and Builder (provide a common abstract description of a complex object that several different strategies can transform to an actual representation). You may find that once you use Strategy, the use of Facade is not necessary.

http://en.wikipedia.org/wiki/Builder_pattern

http://en.wikipedia.org/wiki/Facade_pattern

http://en.wikipedia.org/wiki/Strategy_pattern

So a bit more concrete:

The Facade will have two methods: Log and SetLogger.

If you use Prototype, you will have a type for an Event, and a type for each component of the event. You will only use Prototype if you have a very complex event to log, or need to log it in several very different ways.

There will be an interface for a Logger (Strategy). This is used in the Facade for the SetLogger method. If you are using Prototype, the interface for both Facade.Log and Logger.Log will probably have a method like log(PrototypeEvent e).

Follow link below for a simple logger that does not use Prototype, but does use Strategy. There's no Facade here, as the front-end class really only keeps track of the current logger.

I am going to create simple logger using C# so what are the design patterns I can use to create this as best practice?