Frans,

Have you think about the option to use any DataBase provider at any time, without the need to generate the project with a specific DataBase provider?

May be you can try to use the Strategy pattern with the DataAccesAdapter: - All the DataBaseSpecific project could change to a singleton object that implement a speficic interface, taken away any logic that refer to a specific DataBase provider. This singleton object has all the information about our project that the DataAccessAdapter need. - Each time that we need to create a DataAccessAdapter, we create the specific DataAccessAdapter (Oracle, Sql, etc) passing as parameter the singleton object that implement the specific interface.

But you still need a db specific project to store the persistence info, and the stored procedure call code, or am I mistaken?

in 1.0.2005.1, the DQE's are refactored to be objects with a constructor, no more static classes. This meant that a lot more code could be moved to the DataAccessAdapterBase class, leaving only the very specific per-db code in the dataaccessadapter class.

I'm a little puzzled where the gain is in your proposal, as the current system also offers you to use the code in a generic way: using IDataAccessAdapter in your own code and use a simple factory which procudes the specific DataAccessAdapter instance for the database you want to use. I think that I overlook something in your proposal, so if you could explain it with a simple example why it's better, I'm all ears

Otis wrote:

But you still need a db specific project to store the persistence info, and the stored procedure call code, or am I mistaken?

The new singleton object would has them (persistence info, stored procedure call, etc). This object will implement an interface that will allow the DataBase provider to get all info it need. May be this class could be in the db generic project, in this case the db specific project is no necesary; the other option is to put this class in the db specific project, in this case this will be the only class in that project.

Otis wrote:

in 1.0.2005.1, the DQE's are refactored to be objects with a constructor, no more static classes. This meant that a lot more code could be moved to the DataAccessAdapterBase class, leaving only the very specific per-db code in the dataaccessadapter class.

I'm a little puzzled where the gain is in your proposal, as the current system also offers you to use the code in a generic way: using IDataAccessAdapter in your own code and use a simple factory which procudes the specific DataAccessAdapter instance for the database you want to use. I think that I overlook something in your proposal, so if you could explain it with a simple example why it's better, I'm all ears

Sometime you have projects with hundred of entities + all typed list :

The gain that I see with this proposal is to allow a dbgeneric project to be splited in small dbgeneric project that contain entities that do not have relations with entities in other of the small dbgeneric project. The entities and entities factory will have a property that point to its singleton object (that has all the persistence info, etc). This will allow update entities, from diferents small db generic project, in one transaction. This idea of using a property, in the entities and others class that need it, is better than my previous thought because you do noy need to pass the singleton object as parameter when the generic database specific provider is created and will allow the idea to split the dbgeneric project.

Why split a dbgeneric project? Have you seen the size of the predicatefactory when you have a lot of entities with a lot of fields!

Rogelio wrote:

Otis wrote:

But you still need a db specific project to store the persistence info, and the stored procedure call code, or am I mistaken?

The new singleton object would has them (persistence info, stored procedure call, etc). This object will implement an interface that will allow the DataBase provider to get all info it need. May be this class could be in the db generic project, in this case the db specific project is no necesary; the other option is to put this class in the db specific project, in this case this will be the only class in that project.

It's crucial the persistence info and proc call code is NOT in the db generic project. That difference has to be made to make sure you can use multiple databases with the single db generic project, and to make sure people using the db generic project aren't able to make db calls as they don't have all the info, so they need to call BL code for example to get things done.

Otis wrote:

in 1.0.2005.1, the DQE's are refactored to be objects with a constructor, no more static classes. This meant that a lot more code could be moved to the DataAccessAdapterBase class, leaving only the very specific per-db code in the dataaccessadapter class.

I'm a little puzzled where the gain is in your proposal, as the current system also offers you to use the code in a generic way: using IDataAccessAdapter in your own code and use a simple factory which procudes the specific DataAccessAdapter instance for the database you want to use. I think that I overlook something in your proposal, so if you could explain it with a simple example why it's better, I'm all ears

Sometime you have projects with hundred of entities + all typed list :

The gain that I see with this proposal is to allow a dbgeneric project to be splited in small dbgeneric project that contain entities that do not have relations with entities in other of the small dbgeneric project. The entities and entities factory will have a property that point to its singleton object (that has all the persistence info, etc). This will allow update entities, from diferents small db generic project, in one transaction. This idea of using a property, in the entities and others class that need it, is better than my previous thought because you do noy need to pass the singleton object as parameter when the generic database specific provider is created and will allow the idea to split the dbgeneric project.

Why split a dbgeneric project? Have you seen the size of the predicatefactory when you have a lot of entities with a lot of fields!

Yes, the predicatefactory is a pain. I already looked into ways to get rid of it, and the only way I see is to make it easier to create field objects, which I'll add, so you can simply use the FieldCompareValuePredicate constructor instead of the predicatefactory, and simply remove the task from the generator config. The generated code doesn't rely on it, so you don't need it per se. All methods in the predicatefactory are wrappers around a Field*Predicate constructor and mostly just ease the creation of it by doing the call to EntityFieldFactory.Create() for you. This will be adressed. If you're using C#, it will be even easier with the operator overloads which will create the predicates for you.

I understand what you mean, I have followed that same route with the inheritance info now in the upcoming 1.0.2005.1 release: in the db generic project a singleton is placed with the info. There is a difference though: the info about inheritance is IMHO better of in the db generic project, as it's the same for all databases used. Persistence info isn't, neither is the proc call code. That's why these are in a separate project, so you can use the db generic project without the persistence info and can plug-in an adapter of your choice.

In your case, that's of course not really required, as you're using 1 database with multiple dbgeneric projects. Though if the reason to split them up is the predicatefactory class, then I think solutions to get rid of that class are more appropriate. The class was made to make it easier to write predicates, though in large(r) projects it can become a burden.

Thank you, I will try your ideas.