Hello there, I’m Darren, and I’m a .NET developer living and working in Sydney, Australia.
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Hello there, I’m Darren, and I’m a .NET developer living and working in Sydney, Australia.
Darren's Blog 
Hello Darren, from another Darren.
I thought your ASP.Net Logging Dashboard was awesome. So awesome, I wanted to make it into a more pluggable piece into MVC application. I’m a big fan of MVC Turbine, a small framework that plugs IoC and extensibility into Asp.Net MVC. I took your source code, dialed it back to .Net 3.5 and EF1 (for greater compatibility with other projects, especially mine), and then made some changes to make it flow through IoC, and put it on Github at:
http://github.com/darrencauthon/MvcTurbine.LogReportingDashboard
I also recorded a screencast last night that shows how to set it up:
I still have a few more ideas for ways to polish it up a little more, but it’s quickly becoming something I’m going to want to use on every application. I’d love to hear your thoughts or any ideas you have.
Thank you for all your work!
Darren Cauthon
Olathe, Kansas
Hi Darren,
Thank you for your comment – I really like what you did to the MVC Logging Demo project using MVC Turbine and your screencast. Just adding a reference to the MvcTurbine.LogReportingDashboard assembly is pretty cool!
I’m still learning DI and that is one reason I didn’t put in the Ninject stuff that Rob Conery used for his starter kit into my code as I need a bit more experience with it so it’s good to see someone a lot more practiced than myself do something with it.
I downloaded your code and scanned through it to see what modifications you had to make.
I see that you created a master page for the logging MVC Turbine embedded views – I guess that ties the logging dashboard page to a specific plain-vanilla look and feel and if you wanted to use it as part of an administrative interface in your website you would lose your current admin look and feel and menu items to other admin functions etc.
If the views in the MvcTurbine.LogReportingDashboard project were broken up further so that everything in “MainContent” was taken out and placed into a partial view and then in the “MainContent” content areas you would call RenderPartial(). Then you would have the option to browse to the plain-vanilla pages or you could create views in your own website that called RenderPartial() on the partial views in the MvcTurbine.LogReportingDashboard project. Thoughts?
One of the main configuration pain points is the amount of places in the web.config file you need to put things to get ELMAH configured. Log4Net and NLog can use separate config files. I think Health Monitoring could possibly also have it’s own configuration file. With ELMAH I haven’t explored that yet.
Possible improvements to the dashboard that I am considering: improved charting (eg. most common errors), sections on the details page to automatically grab the top 10 google or stackoverflow search results for that particular error to aid trouble-shooting, links to previous occurrences of that error on the site, a section that shows the previous 5 errors that occurred before the one you are looking at plus the next 5. Plus I need to finish the Manage and Search functions.
GitHub Project – couple of quick suggestions : Remove references to your local databases in the config files and add a sample database to the app_data directory so it can be downloaded and run straight away without worrying about setting up these things.
I look forward to seeing any further improvements you make to it!
Cheers,
Darren
Darren,
I like your ideas about breaking things up into render partials. Another option might be to use display templates, which the user can then override in the main app just by creating a new view in their own shared directory. Then I can make an option to direct the master page that would be used, then… I think we’d have what you’re talking about. The “default” would be something bland and generic, but it wouldn’t be too difficult to incorporate the existing site.
I don’t blame you for not putting in the DI from the starter site. It’s fine, but I don’t think it’s enough. The reason I go with something like MVC Turbine is that it injects IoC throughout the framework. Most of the DI setups for MVC that you’ll see only change the controller factory, so DI is only hit on the controller and not the filters, model binders, etc. Plus, MVC Turbine’s abstraction on the DI container makes it possible to write DI logic and have it work for any of the main IoC containers (Unity, StructureMap, Ninject, Windsor, and Autofac).
I have a few things I’m considering myself:
1.) I’m probably going to leverage IoC, the model binders, etc. a little more in order to shrink the controller.
2.) You might have noticed that I dropped the [Authorize] attribute on the controller. I want to replace it with some type of security configuration that lets a user use some combination of authentication, roles, and a querystring key/value check.
3.) I’d like to make it possible to exclude a logger, if necessary. For example, when I stick this dashboard into my latest live project, I’ll need to make health monitoring conditional since it produces so many logs.
I’d like to move back to the App_Data folder, and perhaps you can help with that. Do you know how I can run scripts against the App_Data database like I did in the screencast? I’m so used to “regular” SQL Server, so I don’t have much experience with that little database in App_Data. I must be missing something because I can’t find anywhere where I can dump a database script (like the ones in your example) and alter App_Data.
Thanks again for getting this started. I’m going to keep moving forward on my end, and I hope that we can share some of the things that both of us do!
Darren
P.S. I wish I had thought of using “dotnetdarren” as my blog name. 😦
Nice
Thanks for sharing it.