The Provider Model in the Real World

Published 08 June 05 10:09 PM | russnem

A friend of mine has his own company called Datex Media that builds real estate managment "portals". These are web sites designed to help his clients view and edit information about buildings, tenants, and vendors quickly and easily. His clients primarily use the database installed with a product called MRI, but he has a few that use Yardi and other technologies. In these circumstances, he forks the code of his real estate business logic framework into a new branch for these clients who stray from the MRI path. Obviously this opens a can of worms. Any improvements his developers made to the main code base are not realized in the branches, so work needs to be repeated.

The provider model is extremely prevalent in ASP.NET 2.0. Several features, including membership and personalization use it. While I was talking with my friend the other day it struck me that the provider model would be an extremely beneficial approach for his company. After all, it seems that he is almost always signing on new clients.

My question to those who read this revolves around the method by which a company like Datex can take their entire business framework (which, unfortunately, contains direct stored procedure calls with the SQL Server platform) and convert it to use a provider type approach whereby he could use his framework for MRI running on SQL Server or Yardi running on Access or any number of real estate packages running on other database platforms.

I have never taken on a project such as this. So much of the data retrieval code already exists in the business framework that I am nervous about something. Would sifting through the hundred classes and thousands of methods and properties to abstract out the data access be task that is worth it? Should a company that is not in a financial position at this point to fund such an undertaking throw caution to the wind and do it anyway? After all, he has gotten along just fine so far. His company makes money with every project. Why should a 400-500 hour project be considered if things are already rosey?

Any input would be greatly appreciated.

Comments

# Mischa Kroon said on June 9, 2005 10:23 AM:

Usually these things work when there are problems with the current way things are done.

If the product is now in it's v1 status.
Then when the product needs to be upgraded because of architectural problems then this kind of thing is usually worth it.

# Geoff said on June 9, 2005 10:52 AM:

I've been using a provider type model for my most recent project and I have to say, there are a lot of benefits of going that direction. The data for the project I'm working on exists halfway between a Progress database and an SQL server. We are in the process of migrating everything out of the older Progress database. Where this has helped greatly is by using the provider to fill the objects we have been able to take inline SQL (I know it's horrible to use those, but our version of Progress does not support stored procs) and convert them to stored procs without any change to any other part of the application.

If he is running into the problem where he is spending more time tracking down these fractured methods that need to be updated with the core changes then he would if he had an existing provider model, then he may want to consider the project.

Leave a Comment

(required) 
(required) 
(optional)
(required)