Reduce Assembly/Database From Old Architecture

[jfrost10]

Hey guys,

We have an application that has to perform automotive calculations from various lenders.

The way this has been coded in the past is to create a business and database layer interface, and create seperate assemblies for each lender. So for instance:
BaseInterfaceBusLayer.dll
Lender1BusLayer.dll
Lender2BusLayer.dll

BaseInterfaceDBLayer.dll
Lender1DBLayer.dll
Lender2DBLayer.dll

Lender1Database
Lender2Database

The problem I see with this architecture is that any change to the main interface means changes to all the assemblies, and we have alot of duplication of code (as well as alot of assemblies running around).

The other thing that I'm not a fan of is how we access our objects: we use the CreateObject method to navigate to the physical location of the lender assembly, and pass in the name of the object we want...just seems so VB6.0ish.

Has anyone had experience with a similar situation, and if so how did you architect the solution? I'd like to look at an abstract class factory possibly as a solution, but I can't find an easy answer for how to dynamically assign the lenders (some clients will have 2 lenders, some will have 3, some will have totally different ones, etc.)

Thanks for any input.

D'Arcy

 

[link9]

The basic approach is sound...

I don't think I would necessarily create separate assemblies for each lender, though. When I approach a class factory, I normally compile the various derived classes into the same assembly, but different physical files to keep things organized that way.

Accessing the objects via CreateObject is definitely old school. What you can do is a switch on whatever id you have for the various lenders to return an instance of the derived class to the caller (masked as the Interface, of course), so:

//This would be in one file, ILender
public interface ILender
{
 ....
}

//This would be in another file, Lender1
public class Lender1 : ILender
{
 ....
}

//This would be in another file, Lender2
public class Lender2 : ILender
{
 ....
}

//This would be in another file, LenderFactory
public class LenderFactory
{
  protected int m_ID;
  public LenderFactory(int p_ID)
  {
    //constructor sends in the ID, which you store
    m_ID = p_ID;
  }
  public ILender GetInstance(int p_ID)
  {
    //overload for setting the id on a per-call basis
    m_ID = p_ID;
    return GetInstance();
  }
  public ILender GetInstance()
  {
    ILender output;
    switch(m_ID)
    {
      case 1:
        output = new Lender1();
      case 2:
        output = new Lender2();
      default:
        throw new ApplicationException("Unexpected ID");
    }//switch
    return output;
  }
}

So what you wind up with is a big assembly, Lender.dll, that has all the classes in it. That cuts down on the PITA factor immensely.

The GetInstance method always winds up being quite lengthy in scenarios where there are many derived classes, but you do keep your wordy method down to just that one, which is a very nice way to handle it (as opposed to having many wordy methods scattered about all your classes).

Now, as far as duplicating code, that can be solved by deriving each of your sub-classes from a master class, which would implement all of the shared logic, leaving each sub-class to only implement the lender specific logic, so:

public class BaseLender
{
  ....
}

public class Lender1 : BaseLender, ILender
{
  ....
}

This bit requires factoring of the various tasks involved in your work. To cut down on maintenance and coding time, you must get the shared tasks into a single base class, which can be sent downstream via inheritance.

To close the loop on the entire process, you change all of your consumer code to program against the Interface, instead of specific classes.

Class factories and Interfaces are just straight from the programming Gods when it comes to maintainability and reuseability. Good luck on getting your system using them.

-paul

The answer to getting answered -- faq855-2992

 

Hey Paul,

Thanks for the response and the comments.

There's one twist though that I forgot to mention in my initial post (and which explains why seperate assemblies were used in the original architecture:

Let's say we have two clients, and three lenders.

Client 1 gets Lender 1 and Lender 2.
Client 2 gets Lender 2 and Lender 3.

The thought back in the day was to have seperate assemblies so only those lenders that were required by the client would be distributed with the application.

I do like your suggestions though, which gave me some ideas of my own on one option: seperation of the common functions through the interface while keeping all the specific business-rules seperated within the classes...sounds very common-sense, but unfortunately the original code mixed the business validation and code into one big mess. As well, each lender relies on their own database to function, so releasing all the lenders in one block may be acceptable if they can't be used without the corresponding database.

Thanks again,

D'Arcy