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

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

                    ActionProcedures.SpSavePersonOptionProperty(themeId, adapter);
            }

rather than this

                    ActionProcedures.SpSavePersonOptionProperty(themeId);

Thanks

Sure, every StoredProcedureCall, whether Action or Retrieval has an overload that accepts an IDataAccessCore (DataAccessAdapter).

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

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.

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

@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.