When to use Adapter:

When the project targets multiple database types and/or multiple schemas/catalogs.

Ok, my application needs to integrate with the Marketing and Sales database (SQL Server), and to be able to fully seperate my business logic, I decided to use the adapter pattern. So, from what I have gathered so far, I need to generate a total of six LLBL projects (Marketing, Sales, WC).

What I am thinking is that I have one component, business.services, who handles all the business process/logic. And all my controller classes inherit directly from a ControllerBase class. This guy is responsible for creating DataAccessAdapter objects and setting the connection string/catalog name, so I can switch dynamically at run-time between production and test mode. Because my application needs to integrate with the marketing and sales databases, I'll use the factory pattern to construct the appropriate DataAccessAdapter object based on the derived class, and return interface references rather than concrete refs.

I guess my main question is that I can't decided if this is the way to go, or have three completly seperate business components, one for each database (marketing, sales, wc).

Anyone else have to do something like this?

If you dont need to extend the functionality of an adapter (aside from which catalog its pointing at) you might just want to have your controller object create an instance of a simple data access adapter, i.e. have your controller initialize it's adapter with a connection string provided by the controller.

If you do need to extend the functionality of a data access adapter, then having the controller call a factory to get an abstract adapter, would probably be the way to go.

You could get really slick, and have plugin adapters. These adapters might be decorated with a custom attribute, that could be parsed by your factory at runtime. Then the controller could also be decorated with an attribute that would map the controller to the adapter to be returned by the factory. When you need to hook into new systems, just create another adapter thats been decorated with your attribute and bam, youre cooking with gas.

However, typically, I havent had the need to create seperate DataAccessAdapter objects, except when I need to take custom actions before, after, or during a given CRUD operation. Usually, my controller classes relate a single entity. An entity is typically related to a functional area or system. My controller class creates instances of a data access adapter whenever it needs to interact with the DB. The controller class knows how to create its own data access adapter.

Hope this helps

Thanks for the reply! I believe in my scenario, I will have to use some sort of adapter factory, b/c I am interfacing with three different database catalogs, thus I can't get by with one adapter. Did I mis-interpret your reply?

After going back and thinking about this a bit more, you most likely will need seperate adapters for each catalog because I beleive there is code in the data access adapter that relates to a specific catalog. So, an adapter for Northwind could not be substituted with an adapter for Pubs, and have the same result. (is this true? I think so?)

This being the case, how do you plan to signal the factory as to which type of adapter your controller needs?

Devildog74 wrote:

After going back and thinking about this a bit more, you most likely will need seperate adapters for each catalog because I beleive there is code in the data access adapter that relates to a specific catalog. So, an adapter for Northwind could not be substituted with an adapter for Pubs, and have the same result. (is this true? I think so?)

After a little investigation, this seems to be the case.

Devildog74 wrote:

This being the case, how do you plan to signal the factory as to which type of adapter your controller needs?

I haven't worked through all the details yet, but any class that derives from controller base (Marked as MustInherit), has to override a property which specifies the type of catalog the class will be dealing with. Then, my adapter factory will return an interface reference to the appropriate adapter based on the property value (enum most likely). I could very well make this more generic using reflection, but for my case, I believe this would be overkill since I know up front which other catalogs we need to integrate with.

HTH

What happens if the developer that creates the concrete controller forgets to set the property? Or would the property in the abstract controller be marked virtual?

Would it be cleaner to provide an argument in the constructor of the abstract controller that sets the enum to pass into the factory? Then you could hide the fetching of the adapter from the factory from the concrete controller and have the abstract controller provide the adapter to the derived / concrete controller.

Devildog74 wrote:

What happens if the developer that creates the concrete controller forgets to set the property? Or would the property in the abstract controller be marked virtual?

Would it be cleaner to provide an argument in the constructor of the abstract controller that sets the enum to pass into the factory? Then you could hide the fetching of the adapter from the factory from the concrete controller and have the abstract controller provide the adapter to the derived / concrete controller.

The ControllerBase is marked as MustInherit with the property marked as must override so the user was not be able to bypass this. Either way would work, however, I do dig the constructor option.