Has anyone tried to refactor the generated DataAccessAdapter class to a completely seperate project? If so, i would be very interested in the templates.

What i am trying to do is the following: i want to create an assembly that includes a factory method for creating a dataAccessAdapter. The actual type to return (SqlServer of Oracle) depends on the parameters passed in. I further want to create multiple LLBLGen projects. For each LLBLGen project i generate the db-generic and db-specific VS-projects. The db-specific projects will in this case exclude the DataAccessAdapter. This mean i must create a way to pass the persistence info to the generic DataAccessAdapter.

As i see it now this would require some additional interfaces (something like IPersistenceInfoFactory). Is that correct?

I am using LLBLGen version 1.0.2004.2.

And what is the use of the generic DataAccessAdapter.

Remarks Use a DataAccessAdapter object solely per thread, and per connection. A DataAccessAdapter object contains 1 active connection and no thread-access scheduling code. This means that you need to create a new DataAccessAdapter object if you want to utilize in another thread a new connection and a new transaction or want to open a new connection.

Walaa wrote:

And what is the use of the generic DataAccessAdapter.

We are using an application framework and a growing number of solutions on top of that framework. De data used is coming from multiple databases. At this moment each solution has its own DataAccessAdapterFactory. However if i want to use the same set of data in another solution i have to create a similar DataAccessAdapterFactory as wel.

I want the factory method to be a part of the framework to reduce the number of copies and create a simpler dependency structure between the solutions.

Walaa wrote:

Remarks Use a DataAccessAdapter object solely per thread, and per connection. A DataAccessAdapter object contains 1 active connection and no thread-access scheduling code. This means that you need to create a new DataAccessAdapter object if you want to utilize in another thread a new connection and a new transaction or want to open a new connection.

I was aware of that. But thanks for the clear description.

Use IDataAccessAdapter in your code, which then will be db agnostic. You then create a simple factory for the DataAccessAdapter classes to produce one for the db you need.

Otis wrote:

Use IDataAccessAdapter in your code, which then will be db agnostic. You then create a simple factory for the DataAccessAdapter classes to produce one for the db you need.

I am already using a factory method per solution and IDataAccessAdapter is used all through the code.

I want to move the factory class to the application framework. It will contain code like this:

public class DataAccessAdapterFactory
{
    public static IDataAccessAdapter GetDataAdapter( .... )
    {
        IDataAccessAdapter daToReturn;
        
        ...
        if (someCondition)
            daToReturn = new DataAccessAdapter( ... )
        else
            ...
        
        return daToReturn;
    }
}

Now suppose i create two LLBLGen projects, module1 and module2. Using the standard templates two DataAccessAdapter classes will be generated, one in namespace Module1.DBSpecific and one in namespace Module1.DBSpecific. Using the factorymethod above i can only create instances from one of the modules depending on wich assembly i reference. If i want to be able to create the adapter for module1 and module2 i'll have to reference both assemblies. And every new LLBLGen project/module i create, i will have to reference. This is not what i want. I want the framework to be more stable than the solutions/assemblies that reference it.

I compared the generated DataAccessAdapter code and noticed that the only difference is the namespace. The trouble is that the adapter needs persistence info in statements like

IFieldPersistenceInfo persistenceInfo = PersistenceInfoFactory.GetFieldPersistenceInfo(field.ContainingObjectName, field.Name);

and the PersistenceInfoFactory can be used because it is in the same namespace. Creating a generic adapter would require a method of supplying the persistence info at runtime.

I think this can be done, but it's a lot of work.

What if the factory is moved to an assembly which governs the dbspecific projects? Then you only have to reference that assembly in your framework, which programs against the IDataAccessProvider interface. Though I'm not sure if this will work though, it could.

Another possibility is to dynamically load the assemblies you want to work with and create the DataAccessAdapter instances using Activator.CreateInstance. Might not be the fastest way to create adapters, but it will be the most flexible.

In v2.0 we created a singleton provider object for the persistence logic and the DataAccessAdapter instance gets an instance of that singleton (well the singleton provider object actually, which contains the provider object to make it threadsafe). This then can be reworked with a templatechange more easily to obtain the persistence info from a factory as well. Still, the factory has to know all assemblies, so the place where you locate the factory, there all assemblies have to be referenced, no matter what.

Otis wrote:

Another possibility is to dynamically load the assemblies you want to work with and create the DataAccessAdapter instances using Activator.CreateInstance. Might not be the fastest way to create adapters, but it will be the most flexible.

That's a usable suggestion. Thanks.

Since we are on a tight schedule, i think i postpone the refactoring to the next major revision. I will then also have the chance to move to v2.0.