Hi to All,

Is there any easy way to use SPs for insert/update/delete with adapter model transparently? (not for select operations) We would like to use LLBLGEN generated entities as our Domain Model, and use the generated adapter for querying.

Our client has a policy using only SPs for update operations. Bad concept or not, this is mandatory. Supposedly theese stored procedures will be generated (not with LLBLGEN) and/or manually written to serve the LLBLGEN adapter needs.

Is it possible to plugin/configure adapter to use them? If not, is it possible to modify adapter templates to do this? Is it a reasonable project or sounds like "you are trying to use LLBLGEN for something what is not intended for"?

thx for answers.

Yes, you can use SPs. I believe you would be using an 'Action' sp. The documentation should give you the details.

Fishy

horo wrote:

Hi to All,

Is there any easy way to use SPs for insert/update/delete with adapter model transparently?

Stored procedures can be called from both Adapter and Self Servicing models. Review this page in the LLBLGen User Manual for specifics:

Generated code - Calling a stored procedure, Adapter

Another useful page deals with wrapping stored procedures in LLBLGen transactions. This may not be usefull in your situation, but it's nice to point out that it can be done.

Generated code - Transactions, Adapter

Hi, thx for your answers.

Maybe my question was not clear enough, sorry about that.

I do know that LLBLGEN can generate wrappers for SPs, and I can call my SPs via this generated code in both SelfService and Adapter.

My question was:

How can I let the Adapter to use theese SPs instead of its dynamic SQL when I call the save method on it.

I do not want to repeat my original question so pls refer to the first message in this thread, I hope with this addendum it will be completly undersandable.

Any ideas?

horo wrote:

Is it possible to plugin/configure adapter to use them? If not, is it possible to modify adapter templates to do this? Is it a reasonable project or sounds like "you are trying to use LLBLGEN for something what is not intended for"?

thx for answers.

Let me repeat what I believe your asking.

You're looking to replace, override, or extend the native DataAccessAdapter behavior to call stored procedure when performing inserts/updates/deletes.

Both solutions are available to you.

These User Manual pages should be helpfull in getting you started extending the classes:

Generated code - Adding your own code to the generated classes Generated code - Extending the framework through inheritance, Adapter

If you decide to go the "modify template" route:

Several example projects are available to you on the LLBLGen.com website in the 3rd Party section of the public webpage. Also download the Template Studio from the Extras section; documentation is included.

To elaborate some further: you can't override automatically the persistence logic with procs. You have to make manual calls to the procs, for example using custom code you add using the techniques Paul suggested. This means that you can't simply 'plug in' a proc as the query to call for an entity to save. You have to manually call a proc and pass every field's value to the parameters of the proc call. This can lead to a lot of code.

(ps: weird policy btw, most of the time, they want procs for selects and don't care for DML)

Hi,

Thx for answers both of you.

I am going to check the extras.

I still have doubts on:

Is it a reasonable project or sounds like "you are trying to use LLBLGEN for something what is not intended for"?

horo wrote:

Hi,

Thx for answers both of you.

I am going to check the extras.

I still have doubts on:

Is it a reasonable project or sounds like "you are trying to use LLBLGEN for something what is not intended for"?

In theory, yes, LLBLGen Pro wasn't designed to use procs for DML operations on entities. This is because the entity definitions are set in the code you use and the procs aren't part of that. This is a fragile setup, as when the procs change, the system will fall apart at runtime, unless the entities are still matching the changed procs. The errors however are hard to track down, as they occur deep inside the runtime libs, and the cause is unclear at that point: bug in the runtime lib? faulty proc? To avoid that, the SQL is generated from the meta-data of the entity, and the data inside the entity. This then doesn't create these mismatches.