Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Require adapter in RetrievalProcedures/ActionProcedures
 

Pages: 1
LLBLGen Pro Runtime Framework
Require adapter in RetrievalProcedures/ActionProcedures
Page:1/1 

  Print all messages in this thread  
Poster Message
hotmail
User



Location:
chicago
Joined on:
06-Feb-2013 05:17:38
Posted:
44 posts
# Posted on: 29-Oct-2015 12:46:03.  
Hello
Using LLBL v4.2 Adapter, SQL server 2014, VS 2015

Is there an option to require passing adapter in every RetrievalProcedures/ActionProcedures by default?

i want this

Code:

            using (DataAccessManager adapter = this.dah.GetAdapter())
            {

                    ActionProcedures.SpSavePersonOptionProperty(themeId, adapter);
            }


rather than this
Code:

                    ActionProcedures.SpSavePersonOptionProperty(themeId);


Thanks
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14588 posts
# Posted on: 29-Oct-2015 20:01:54.  
Sure, every StoredProcedureCall, whether Action or Retrieval has an overload that accepts an IDataAccessCore (DataAccessAdapter).



  Top
hotmail
User



Location:
chicago
Joined on:
06-Feb-2013 05:17:38
Posted:
44 posts
# Posted on: 30-Oct-2015 04:05:50.  
i understand there is an overload, but if i am using adapter (not self serving) why wouldn't Procedure be required to instantiate adapter just like i am required for Fetches, i have my custom method instantiating adapter where i pass more information like user id, but because procedure does not require adapter...sometime our developer simply calls the procedure (without overload) which may result in run time error because other data was not passed.

....may be an option for V5?


Thanks
  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8110 posts
# Posted on: 30-Oct-2015 07:18:16.  
Actually the overload that receives the adapter instance is for developer's convenience. If you don't want that, you could create you own custom template that overrides the normal one. Check the SDK Docs for more information about this.

David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
JSobell
User



Location:

Joined on:
07-Jan-2006 06:44:46
Posted:
89 posts
# Posted on: 30-Oct-2015 13:14:31.  
hotmail wrote:
Hello
Is there an option to require passing adapter in every RetrievalProcedures/ActionProcedures by default?


The main issue is that without specifying the DataAdapter instance the use the system would have to create a new one each time, so you would have no control over the transaction or connection it was using, unless you created a single static DataAdapter that was shared by all calls (and that's not a good idea).

If you're using IOC and you have control over the scope of a call, you could have a per-request or per-instance adapter injected into every class, but overall it's much safer and wiser to track and understand the adapters used.

If you want to call lots of SPs within a short space of time and (for some odd reason) don't want to pass the adapter in, create an IDisposable class that takes the adapter as a constructor, and write your call methods on that class, each calling the appropriate stored proc using the stored data adapter value. This is essentially a repository pattern.

I'd recommend you forget about saving a few characters on each call and pass in the DataAdapter as required.

Cheers,
Jason
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37879 posts
# Posted on: 30-Oct-2015 14:56:11.  
@JSobell, I agree, I think though the problem is that the developer has 2 methods to choose from and sometimes can call the overload without the adapter in the signature which will go unnoticed unless a transaction goes wrong because of that.

@Hotmail: is the above a proper understanding?

I indeed think for now you should run your own template and not generate the overloads which don't accept an adapter.

If the adapter used in your code is produced by a specific central method, you could also opt for checking whether the adapter used is one created by your method instead of one created inside the proc method, by adding a property to the partial class of DataAccessAdapter and setting it in the method which creates the adapter, then override the 3 Call*procedure methods the same partial class and test there whether the property is set to a value (so it's created by your adapter creation method and thus a valid call) or not (so the adapter is created inside the proc method, which means the dev called the wrong method) and throw e.g. an exception there.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.