What's the best way to log in ASP.net MVC? I mean any event, I'm currently using NLog but I know there are a lot of possible ways to do it.
I use log4net, its quite good. There are some issues to be aware of, you can learn more about them here. I also recommend Elmah, for me I use it on every project I do, its a prerequisite.
I don't think there is a best framework/tool or standard way in ASP.net MVC. Just do it the way you would in any other framework. When I set up logging, I usually think of it as a resource available to the rest of the application, rather than being tied to a particular tier. This is common, and in fact logging is the standard example given when introducing Aspect Oriented Programming. See:
Logging mentioned in the wikipedia entry on AOP
Another AOP into that uses logging as the example
Depending on what exactly you're trying to log, consider using action filters; a great way to log what page requests are made and for error handling coverage. Non-MVC asp.net apps usually do something in the global.asax, as mentioned here. In fact, even if you use the action filters, which I would suggest, also include some basic error handling in the global.asax 's application_error event; it will fire a little more dependably than the action filters if something really crazy happens.
Other than that, call your logging resource at the point where the stuff happens that's interesting to you. DB or File? Either works, and as long as it's encapsulated in a good method or two, you can always switch that later.
Related
Well, I'm just learning ASP.Net, and after reading some books I found that there are this things called Modules which tweak a Request and Handlers that (I think) tweak a response. The problem is that I can't understand how they really work, so I prefer just skip this part and come back to them when I get a bit more comfortable with the ASP.Net framework.
My question is, are they a big part of this framework? Am I going to use them a lot?
ASP.NET modules and handlers are definitely important, but typically they are secondary to pages and services: so it is reasonable to focus on pages and/or services first.
As your understanding grows, modules and handlers will probably start to make more sense when you revisit them.
Having said this, a related SO question explains ASP.NET modules & handlers about as simply as one could hope for.
Is there a way to test if the current request (HttpContext.Current.Request) is available in the Application_Error event of the Global.asax when using Integrated Pipeline with IIS7 in ASP.NET? Currently I am using a try-catch, but it seems like there should be a way to verify rather than catching an exception.
Unfortunately, I believe the answer to your question is no. This question seems to cover what you're asking. You can use reflection, but it doesn't seem very reliable. Articles like this blog post recommend not doing this, and even say:
"Because this event is intended for global initialization activities, any logic that references a specific request is typically a design oversight."
But what does he know about the design of your site, amirite? Your only choice if you really want this is to go back down to Classic.
Disclaimer:
This is the first time I am asking a question that might be classified as subjective. As English is not my first language, it is hard to phrase this right. So please feel free to edit the question in order to make it clearer, or to point me at other ways for asking this.
Intro:
David Ebbo (architect on the ASP.NET team) just posted on Register your HTTP modules at runtime without config using the seemingly undocumented PreApplicationStartMethod assembly level attribute
I have mixed feelings about it.
On the one hand it is good to be able to do things as early in the application startup phase as possible.
On the other hand: Does it suffice? Do we need a PrePreApplicationStartMethod allowing to fiddle with the PreApplicationStartMethod behaviour? What about expansion to non-assembly use (for instance, NuGet already works around the single-use-per-assembly restriction of PreApplicationStartMethod)?
Question: Besides using it for config-less startup, what do you think of the PreApplicationStartMethod attribute?
I think one of the good usages for this is that it allows someone who is writing a 3rd party assembly, or a team that is working on an assembly that will be used in many projects, to be able to use this attribute to initialize stuff w/o requiring the end user/developer to create anything in the global.asax in the application startup events.
There are lots of app specific stuff that people like to/need to configure in global.asax, but if you are creating a DLL, you no longer have to make the user configure your classes in the global.asax, you can just put all your logic in your own init/bootstrap function and rely on asp.net to call your init logic when the app starts.
My application needs to log informations about user actions (inserts, updates, deletes, etc) and exceptions and i want to store de log on Oracle10, so i'am searching some log framework to use.
I read a little bit about:
1 -Log4Net
2 - Logging Application Block
3 - Elmah
Whats your opinion about these log tools?
Whats a good framework (or way to implement) log on my application?
*After a discussion with the project manager, Logging Application Block
will be our choice, but, lets comment about this =)
Both log4net and Logging Application Block are valid choices. I think ELMAH is mostly focused on error logging, so that is probably not (the only thing) that you want.
At work, I use log4net on a couple of projects. It is stable, performant and extensible, and we have never had any problems with it.
I would probably do logging with log4net and log exceptions with ELMAH also. It can log unhandled exceptions manually, and any exception you catch and handle in your application can be logged with a single call to ELMAH. This might seem like double-logging (and it is :-)). But it is very valuable to have the ELMAH log when something unexpected has failed in your application.
I have heard good things about the NLog project, but haven't used it myself. It seems to be a bit more complex that log4net, but does have the added benefit of being able to add contextual information to log messages automatically (a bit like ELMAH).
My opinions about the different frameworks:
Log4Net - Love it. This is the logging system that I use most often. Everything is fairly easy to get started. It's also very flexible and allows you to log just about anything.
Logging Application Block - Also a good option. I still prefer Log4Net (but the reasons are mostly personal).
Elman - Great for dropping in to an ASP.NET application to log Exceptions. For general message logging though, I would still go with Log4Net.
And I'm guessing based on my opinions what I would suggest you do...
And if not, use Log4Net and create an Adapter you can use in your application to make logging simple.
I personally like BitFactory.Logging because it's lightweight and uses the right amount of abstractions to make the calling code easily testable.
That said, the things you want to log (inserts, updates, deletes) could be logged using only triggers, a solution that might perform better depending on your setup.
I personally always create a wrapper anyway, so I have my own ILog implementation, that works with whichever of these that you choose. This makes it easy to swap in or our implementations.
I tried #2 but it was kind of a pain; #1 would have worked out well for us but we didn't go for it, just went simple custom logging. All I know about #3 is that I know of someone having trouble implementing it in their org. Don't know why, but it actually looks pretty interesting. I don't think you can go wrong with any personally. It partially depends on the API that you like.
HTH.
Log4net is quiet good, it is basically a version of log4j. Elmah is nice also, especially if you find (like me) that you are unable to write to files on the production environment, since it writes to the DB instead. Also, Elmah is more suited for exception logging, and is cool because it allows you to log based on events. In my projects I normaly deploy both log4net and Elmah
If you are auditing data changes in a db then you can use triggers on the relevant table.
For logging in a dotNet app use TraceSource to write logging info and a custom TraceListener to write to a db. Don't need a framework beyond the base class library really.
I am making a site where users can reply to topics, open topics, etc. and when the user sends a message, I don't want to postback; it's ugly.
I'm using generic handlers right now but I am having some problems with it. Like updating GridView using UpdatePanel when XMLHttpRequest's onreadystate is changing.
I decided to use PageMethods but I also wanted to ask you.
Which is better, faster and more useful: PageMethods or Generic Handlers?
I don't think there would be much difference between the speed of Page methods and HTTP Handlers. However if you're worried about your application's performance, you should benchmark each option and choose what's best for you.
To answer the question, which is better or more useful, basically within the ASP.NET context you have three options, each with their pros and cons:
Page methods - all your code is contained in single Page, which is fine if the code is only used by that page. You should probably implement methods that return page-specific HTML snippets as Page methods. However if we are talking about reusable code, such as "Save Topic" or "Get Topics", you might want to consider externalizing this code elsewhere. I guarantee that as your application grows, you'll need those methods elsewhere in your application end as well.
Generic HTTP handlers - are lightweight, and great for code you need to call often throughout your application. Most often generic handlers are implemented to serve content, and I don't know what the best practice around this topic is, but to me POST ing to a generic handler to save data has a distinct smell. You'll also find that for related functionality (Save, Get single, Get many, etc.) you'll end up with a swarm of handlers, or a handler with a giant switch statement and a fuzzy contract based on query string and POST parameters. I wouldn't recommend this option to implement extensive AJAX application. For small bits and pieces it might suit your needs.
ASP.NET web services (or WCF) - The third option you did not mention in your questions are ASP.NET web services (.asmx). You can easily include them in your existing ASP.NET application without any additional framework dependencies. They offer a good balance between the options 1 and 2. On one hand you get reusability throughout your application, and even outside your application if you so choose, which Page methods cannot provide. On the other hand you can neatly bind together related functionality in meaningful ways, which tends to get messy with generic handlers. You can also interact with the services using SOAP XML, JSON or HTTP POST / Plaintext as needed.
And the wildcard option here is: Use ASP.NET MVC and jQuery. If you're looking to build a lean and mean web application and you generally find postbacks ugly, and you find stuff such as what exactly happens when the xmlhttprequest changes readystate interesting, it might provide you with a better experience overall. Maybe not for this project, but for the next one.
If you mean with generic handlers web service endpoints then you can make the following distinction:
You can use PageMethods if the functionality only needs to be available on that page only
You can use web service endpoints if you want to reuse the functionality.
Personally I practically always use web service endpoints (in my case ajax enabled WCF).
I cannot see why you shouldn't use generic handlers. I think they are best - simple and flexible.