Currently doing a project in .NET CORE, where i am going to have various layers, including a CrossCuting layer, but i cant get my head around this problem...
right now i have a Logger working all fine, using Serilog. But my problem now is, i want to Have my logger created and configured inside the CrossCutting layer, and then injected into the Application layer(for now).
Is There any possible way to do that? So many articles explaining how to do the configuration trough Program.cs but what about inside a Layer?
In order to correlate logs that belong to the same request, even across multiple applications, add a CorrelationId property to your logs.
Here you have Serilog best practices:
https://benfoster.io/blog/serilog-best-practices/
Related
Is it possible to have multiple serilog loggers? Currently within my WebApi I can call Log.Information for example to log an information event, but is there a way that I can instead make different logs and call ExternalLog.Information or AuthenticationLog.Information from my controller? The purpose behind this is that my web api is currently working with multiple different databases for different yet interrelated projects, and I would like to store logs within each of these databases that pertain to them instead of needing to create an additional logging database if at all possible.
A better solution, that I figure is less likely is, can I map individual controllers to a log, so that any time that a specific controller calls log, it writes to the AuthenticationLog for example.
I believe that the answer to this question is to use subloggers, rather than separate loggers. I have found that you can do .WriteTo.Logger and filter further in there. I will accept this as the answer if nobody else has a better solution (and of course if I am able to get it to work). I need to be able to filter on the controller or action name, which at this time I have a second stack overflow question out to figure out how to get that data. Serilog with Asp.net Web Api not using enricher
I just ran into a problem with my project. I have my MVC website where my ViewModels live, in second proejct i have BuisnessLogic(services) where i have all my funcky logic going on before it gets from db to the view or the other way arround.
Before, i had my ViewModels outside of the web project together with my services, but now after i moved them inside the webproject my services are crashing, because my services used to return ViewModels and they no longer can get them because of the circular dependency, since website need to get service methods, and services need viewmodels. So basicly i am confused right now, and cant figure out which way to go.
Should i just move Services up into website project together with ViewModels? Or have i misunderstood the purpose of the services in MVC? Or maybe there are some other way to keep serivces separated from web project?
There is no official documented way or standard best practice for this. It is up to you. Some people like that about MVC others think it creates unorganized code. Just maintain 3 tier architecture and you can't go wrong.
MVC + 3 tier; where ViewModels come into play?
I'm working on a project where I'm required to use Enterprise Library v.3.1.1.0 Logging block (wish it was log4net or nlog, but I don't get a choice). We have an IIS application where several WCF webservices are hosted, and they share a single web.config file. This is also something I'm not at liberty to change.
None of these services had any logging implemented previously.
So it's pretty straight forward to use the Ent Lib Config utility to set up a rolling flat file listener, and log to a text file the way I want. The problem I'm having is configuring it properly though so each service can have their own separate log file, while they still all share the same web.config.
I've gone through several tutorials, but I'm not understanding how to do this.
Any tips?
The configuration in the web.config is static so there will be one file per configured trace listener. One approach to achieve one file per service is to have each service log to a different category and each category uses a different trace listener. This could even be done programmatically so that services can add their own trace listener's at runtime although this is a bit more advanced than updating the configuration file manually (e.g. ensure service is added only once as well as ensuring that when the configuration is updated it is thread-safe).
Enterprise Library does not have anything analogous to log4net's hierarchical loggers so there is no out of the box way to use reflection to route log messages based on the originating class. It might be possible but you will have to write some code. You could write a Logger facade class to set the category based on the callers namespace. (Also note that there is no namespace wildcard matching like log4net.)
What architecture and patterns can I use to share the most model and logic code between a WPF and an ASP.NET MVC application?
I am trying to achieve a bit more here than just separating my data entities from the two presentation projects. There is a lot more in common e.g. UI logic on what gets displayed under what conditions, when is something required, etc. that I would like to keep in the shared code.
ADDED: I am just beginning to really like the concept of view models independent of my entity model driving my presentation. While some of the annotations used in these are located in assemblies specific to MVC, none of the metadata provided is actually web specific. I would very much like to explore using my MVC view models as data sources for binding to WPF views. Any suggestions on this front will be most appreciated.
My personal favorite configuration is similar to the one Adam King suggested above but I like to keep the logic DLL as part of the web project. I run a project called CT Terminal that follows this pattern. My Terminal.Domain project contains all the application logic and simply returns a CommandResult object with properties that act as instructions to tell the UI project what to do. The UI is completely dumb and only processes what it's told to by the Domain project.
Now, following Adam King's approach I would then slap that Domain DLL into a WPF app and then code the UI to follow the instructions in my returned CommandResult object. However, I prefer a different approach. I wrote the MVC 3 UI to expose a JSON API. This API can be consumed by any application. The JSON API was simple because it was basically a wrapper around my Terminal.Domain project CommandResult object. The JSON returned would have the same basic properties. In this way I would write the WPF app to consume this API rather than the DLL. Now if I make minor changes to internal application logic I just deploy the Web project to the live server. All clients using the API automatically get this new logic.
Obviously if the changes being made affect the properties being returned from the API then that would require a release of new client code, but at least for internal logic you wouldn't have to do that.
One of the most widely used patterns seems to be having the Entities in a seperate DLL assembly, then having this referenced from each of the other projects.
MVC 3 suits the repository pattern very nicely, which can be a clean route to take in the first instance, and will work for both WPF and ASP.net
I actually found Rocky Lhotka's books, software, and videos on this topic very helpful. Here's a few links to his content:
http://www.lhotka.net/
http://channel9.msdn.com/Events/Speakers/Rockford-Lhotka
http://www.amazon.com/Expert-C-2008-Business-Objects/dp/1430210192/ref=sr_1_2?s=books&ie=UTF8&qid=1331834548&sr=1-2
Create a service layer for your application by specifying interfaces with methods that represent all of the operations you need to perform. Also, in this service layer, define all of the data types used by the application. Those data type classes should contain only properties, not operations. Put these interfaces and classes in an assembly all by itself. This assembly should be shared between your web app, WPF app, and the code that implements it.
Finally once you have this separation, you can freely develop the application's internal structure, and leave the responsibility of UI operations (e.g. what happens when you click xyz button) to the respective UI.
As an aside, you can expose your service layer, via WCF and web services. You can use this to make call from the web browser via javascript. You could do things like client-side validation or even look up values on the fly for drop down population. all while reusing it between your two application.
Starting with the obvious. Encapsulate your business logic and domain model in a separate assembly.
In terms of Presentation Layers and shared UI Behaviour, the closest you will get is the MVVM design paradigm, implementation will be C# in WPF/XAML and Javascript for your ASP.NET MVC web frontend.
For the web frontend you can get close to the WPF (MVVM) way of doing things with http://knockoutjs.com/ written by Steve Sanderson of Microsoft. Its MVVM for the browser. Also checkout http://www.asp.net/mvc/mvc4 for more info.
Use Web Api, let both the WPF and the Web application consume the services from Web Api.
Done.
Did you try using Portable class libraries. With this you can make the data layer and use it in ASP.Net MVC, WPF, Windows Phone, Silverlight.
I've got a basic asp.net MVC project that has a Web project, a Service dll project and a Data dll project. I started to store config values in the web project's applicaiton settings but I've come across a few instances where I need them in the service layer. The only way I can think of sharing the values is to pass them to the service layer via parameters. Is there any other way of having one config value that is accessible to all projects?
I tend to keep config tied to the outermost layer (where it is defined in app.config or web.config) and have that layer explicitly pass through any values which are needed for domain or infrastructure logic, which should be what your lower level layers contain.
I find the notion of having config values contained in the outer layer which are 'magically' used by lower level layers to be rather non-intuitive and opaque.
I know this has been answered .. but .. you should never have any dependencies on *.config files in service or data layers. This ads some very tight coupling. The best way is to get them passed in via parameters .. like via constructors.
Even in your website you still shouldn't, IMO. I would use Dependency Injection and inject them into the Controllers, if you really need them. why? Well -> unit testing. Unit tests shouldn't require any *.config file. As such, if your controllers are passed in the data, then your code has no dependencies now -> which is awesome.
Here's an example of a controller that has no dependencies on a web.config and here is how the app setting entries are passed into the controller VIA dependency injection.
Check it out :)