Showing posts from February, 2020

Choosing Dapper over EFCore

Recently I've been introduced the wonder that is Dapper, now understand most of my experience has been with Entity Framework and honestly found it hard to walk away from a framework that I love and been using since the beginning of my career. However for my current role I need to be more team oriented so its whatever gets the job done. This article will serve as a timestamp so that I can look back. So far its been four months using it and I do find myself using Dapper like EF but with more freedom. I have left concern about what I'm mapping to but just that I've mapped correct. Which I look at first in sql for the correct column. I've written more sql compared to what I wrote with EF. I think that says a lot about Dapper but its hard to say since I've also become more comfortable using sql. Overral Dapper is a lot easier to use. Notes Raw Queries in EF

Custom Logging with Personal Fields in Nlog

Setting the database string via var databaseTarget = ( DatabaseTarget ) LogManager . Configuration . FindTargetByName ( "database" ); databaseTarget . ConnectionString = connectionString ; LogManager . ReconfigExistingLoggers (); The above didn't work but I used the example below where I set it via the the start of the program. var defaultConnection = Configuration.GetConnectionString("DefaultConnection"); NLog.GlobalDiagnosticsContext.Set("defaultConnection", defaultConnection); var logger = LogManager.LoadConfiguration("nlog.config").GetCurrentClassLogger(); Then you can use ${gdc:item=defaultConnection} in your nlog.config: <target xsi:type="Database" connectionString="${gdc:item=defaultConnection}" /> Rather than using GDC, which is for global static data and fails on concurrent logging, it is better to use  EventProperties-Layout-Renderer  that allows to pass custom  properties specific for th