Non-Csla code with Csla

[Chicagoan2016]

Hi All, We have to use some third party libraries in conjunction with Csla, e.g. if we have to use one of the open source logging frameworks, should we write own Csla wrapper classes around the logging framework code? My concern is, since Csla objects are 'mobile' if we use the logging framework classes inside our business objects, the logging framework code might not serialize and potentially not available when Csla business objects move across the wire.

Kind Regards

Version and Platform CSLA version: 4.7.100 OS: Windows, Linux, iOS, Android, etc. Platform: WinForms, WPF, ASP.NET Core, MVC, Xamarin, etc.

[rockfordlhotka]

It is unlikely that those other objects are serializable at all. Especially logging, which is usually designed to be per-machine.

So you don't want to try and wrap them in serializable objects - I can't see how you could even do that in the general case.

Instead you want to make per-machine (or per-AppDomain) instances of those objects available for use. You can do that using a service locator pattern, or by adding references to them into the Csla.ApplicationContext.LocalContext dictionary. The dictionary is a bit of a hack compared to a service locator, but should work fine.

Another option is to use dependency injection, at least in the server-side data portal, where the hooks exist to integrate IoC containers into the standard data portal processing flow. @JasonBock wrote a nice blog post on how to do this a couple years ago.

[jonnybee]

For tracing you could also use the built-in System.Diagnostics.Trace and TraceSource and then just route the output to a log file through NLog og other log frameworks. Only needs a few lines in web.config

See https://nlog-project.org/2010/09/02/routing-system-diagnostics-trace-and-system-diagnostics-tracesource-logs-through-nlog.html and https://stackoverflow.com/questions/16056362/using-net-trace-and-then-nlog-or-log4net-etc-as-a-listener