Jun 14
Eric.Net, Development Asp.Net Mvc, Nehemiah Project, Ninject
Our last post saw the creation of two logging services utilizing NLog and Log4Net. In this post we’ll add Ninject to our template and use it to inject the logging service of our choosing.
Let’s not kid ourselves. Most of the development work on an application is done after deployment. No matter how well written the original application is, someone will be replacing part of the application sometime in it’s lifetime. If you’ve ever worked on a project where you’ve had to change the data repository or logging service or email service, you know how frustrating it can be when the core code and your service (i.e. data repository) are tightly knitted together. We touched on this subject in our previous post, Part 14, Services and Interfaces.
More
Jun 07
Eric.Net, Development Asp.Net Mvc, Log4Net, NLog, Project Nehemiah
One of my goals with the Nehemiah Project is to make sure the ASP.Net MVC 2 Application template is modular and extensible. What happens when MVC 3 is released? We certainly don’t want to lose all our hard work. What happens if you want to use a new or different ORM? The template should allow the user to easily replace existing components and add new components in either the template or the solution built from the template.
This may be very basic for many readers, so you can jump straight to the code below if you wish. If you know the how and why of interfaces, services, and dependency injection, by all means jump ahead.
Let’s begin by breaking down the parts of the Model-View-Controller framework. The Model represents our objects that are manipulated within our code. The View represents how our models are viewed. The Controller is the traffic cop that directs the flow of the models. So what manipulates our models?
More
May 31
Eric.Net, Development Asp.Net Mvc, Nehemiah Project
In part 13 in the Nehemiah Project series we’ll complete the Custom Profile Provider. The profile provider is a generic storage feature and gives our web application the ability to store unique user information. In the profile we can store such items as a web layout, color scheme, zip code, or billing and shipping addresses.
Then why write the custom profile provider. Well, to give us options. If you don’t like the way the SQLProfileProvider stores data you now have your own method. Or if you need to retrieve the data from an existing database or service you have an example of writing the specs and an implementation that can be modified to suit your needs. More
May 24
Eric.Net, Development Asp.Net Mvc, Nehemiah Project
We began writing the custom role provider in part 9 of this series. In today’s post we’ll finish what we started in part 9. This will be nearly all code and no fluff commentary. Ok, maybe a little commentary.
When I initially ran through this exercise I had a separate repository for User, Role, and UserInRole. Which I felt was a bit ridiculous since these three will almost always be used together and I didn’t feel the need to pass a separate repository for every POCO that might be read or modified from our data repository. So I merged all of them into the IProviderRepository interface. These are the kinds of things you run into as build and learn as you go. More
May 17
Eric.Net, Development Asp.Net Mvc, Nehemiah Project
In part 8 of this series we began creating a custom Membership Provider. We’ll finish our custom Membership Provider with this post. This entails expanding our specifications, finishing our membership provider code, and writing a mocking class for our data repository. More
May 10
Eric.Net, Development Asp.Net Mvc, Nehemiah Project
This is the third post on adding custom providers to our MVC2 template project. This post will simply setup the skeleton specifications and code for our own custom profile provider.
Add a class file named ProfileProviderSpecs.cs to the Providers folder in the Nehemiah.Specs project. Here’s our specifications for the custom profile provider. More
May 05
Eric.Net, Development Asp.Net Mvc, Nehemiah Project
In this installment we’ll add the specifications and the skeleton code for a custom role provider. Start by adding a class file to the Providers folder in the Nehemiah.Specs folder. Give the file a name of RoleProviderSpecs.cs.
Here is our skeleton custom role provider. Just like the membership provider, these specs will be expanded upon in the next post about the custom role provider. More
May 03
Eric.Net, Development Asp.Net Mvc, Nehemiah Project
This post will be more code than explanation. As will the next two posts. I want to get an outline of the code necessary to build our own custom membership, role, and profile providers. Once we have the outline, then we’ll expand our specifications, write our code, and we’ll probably need to add Ninject into the mix during this and the next five or six posts. More
Apr 29
Eric.Net, Development
The .Net Rocks guys, Carl Franklin and Richard Campbell, made a stop in Tulsa on their Road Trip across the US. If you’ve ever been to a technical conference, symposium, or gathering of any type, you know they can be extremely boring. Plus there’s always the risk that you run into the guy who “in the old days” etched the code bits on silicon. You know the guy, usually with an IQ north of 200, talks non-stop, and doesn’t let anyone else add to the conversation. So unless I’m there with people I know, I tend to stay away from these kinds of events. More
Apr 26
Eric.Net, Development Asp.Net Mvc, Elmah, Project Nehemiah
In this installment we’ll add support for our custom web errors and add support for Elmah.
Custom Web Errors
First we need to write our specs. In the Controllers folder of the Nehemiah.Specs project add a class file named ErrorControllerSpecs.cs. Initially we’ll write a single generic error page. So there will be only a single test. Our specs look like this. More
Older Entries Newer Entries
Recent Comments