We have written numerous web applications and have found that we often are doing the same base-infrastructure tasks in most of them. To help speed up our development process and provide a level of consistency in how we manage certain tasks we have created a set of extensions and helpers to assist our ASP.NET and Web API Development efforts.
This library is available as an MIT open source piece of software on Nuget under SoundPower.Web or at https://www.nuget.org/packages/SoundPower.Web/.
User Notifications
In almost every application we often need to add a series of messages (error, warning, information, success…) during processing of a request to be displayed to the user. To facilitate this, we have created a Notifications class where a simple command will add notifications to the stack to be rendered with the page. A method to automatically add all the error and warning messages from a Base Response class is also included.
Then when the page is being drawn we simply call the RenderNotifications command which pulls all of the messages out of the queue built up (clearing it) and renders a series of DIV objects for those messages. Each DIV object has a CSS class of alert and a glyphicon-XXX to reflect the type of message with an X to be displayed at the far right of the message to allow the user to dismiss each message individually.
Messages can be added during the request. However, MVC workflows often involve a redirect call which breaks the “net” request up. This system supports that. While it will use the current user’s ID combined with the runtime cache of the application between such requests combined with the current context’s cache to track the messages. If working with a new user or unauthenticated user, there is a method in the Utilities class to set the ID of the user to support the re-routing of responses.
Error Handling and Logging
The Utilities class includes methods for logging errors and events. Errors must be encapsulated in one of our advanced exception classes. Both attempt to log the action to a configured Application Insights instance. If this cannot be done or is not configured, the application will log the action to the server’s application event log under the source named in the “sps:LogSource” of the appSettings in your web.config file. During deployment, administrators must make sure the web application has access to make entries under that source by adding it in the server registry under the application log and granting proper permissions.
The library also has a custom error handling attribute that can be used by naming it in the filter config class of your application. This will ensure any error is captured, wrapped into an advanced exception class and logged before sending the user to a view to display information from that wrapped error. Usually our engineers set it up to display the logged error number and the public message from the error. If there is a logged in user, this filter will automatically include the user’s ID in the data list logged with the error. It is also able to differentiate between JSON requests and normal web requests and send a Response Base object back for JSON request errors.
Web API Helpers
When building out REST services, we found that we were often coding several actions repeatedly. To minimize the workload we were doing and increase the maintainability of API controllers we created a base class add-on to the standard ApiController class. It includes a method to automatically set the language and culture used in reading resource files to match that of the request. It also includes a method that will automatically log a base exception and return an HTTP Response Exception (Code=500) with the logged error number in it that can be thrown back to the caller. Lastly, it includes a method that returns an HTTP Response Exception with a code of 402 and a serialized version of a response base to be used for returning business and validation rule failures under a notable HTTP code.
