Hi ppl,

I am currently evaluating LLBLGen Pro for use in a new project and after having played with the demo the last 3-4 days I have a couple of questions.

1) While we are currently developing using an Oracle back end, we would like to keep SqlServer as an option. I believe I understand the Adapter approach and the AdapterFactory approach proposed elsewhere. But what if I want to use the the DataSource control (which is mandatory to convince my fellow developers). How can I configure it to use the correct Adapter type each time and keep the Designer support working?

2) Can I download and use the project conversion to another DB tool (that I read about) with the demo version before moving to a purchase?

3) I read somewhere that lazy loading works only with the Self Servicing paradigm. Does this mean that all relations are eagerly fetched (even large collections) or that I have to explicitly ask for them through some extra code? (feel free to flame me for this question )

Disclaimer I am a Java guy doing his first ASP.NET project. I am struggling to turn my team away from SqlDataSource and in to a Layered approach with O/R tools. LLBLGen seems great so far (especially the feature/cost ratio is excellent).

1. if you're using the LLBLDataSource, set the AdapterToUse property to retrieve an IDataAccessAdapter from the DataAccessAdapterFactory.

2. I'll leave the official answer to tech support.

3. with adapter only data you specify is fetched. once it's fetched you will need another adapter object to fetch more data. so say you want all orders on a given date with order details. you would start with an order collection and prefetch order details. if you then needed to fetch all customers you will need to use the orderentity collection to fetch related customers.

if you use a N-Tier approach I would abandon datasources all together. just bind an enumerable collection to the GridView directly.

2) I think you will need a license.

3) Even on SelfServicing you can disable LazyLoading by providing prefetchPaths. On Adapter only what you specify is loaded when you specify it.

Hi guys,

Thank you for your replies.

jmeckley wrote:

1. if you're using the LLBLDataSource, set the AdapterToUse property to retrieve an IDataAccessAdapter from the DataAccessAdapterFactory.

Using the demo version of LLBLGen, I can't find the AdapterToUse property of the control.

The control has the AdapterTypeName property which can't be hardcoded since I want it to refer to a different namespace in each deployment according to a configuration value (say from web.config).

I want this change to be configured before deployment. Once deployed the application will use only one database of the configured type.

Chris

Just a followup,

jmeckley wrote:

if you use a N-Tier approach I would abandon datasources all together. just bind an enumerable collection to the GridView directly.

This call is not completely up to me to make! Also, for simple CRUD operations I think datasources are practical and allow the full use of the VS.NET Designer. Sometimes too much abstraction is simply more code to write and maintain!

Chris

ChrisCY wrote:

for simple CRUD operations I think datasources are practical and allow the full use of the VS.NET Designer. Sometimes too much abstraction is simply more code to write and maintain!

Very true, not need to work harder for the same results. If your developing using TDD or Agile development methodologies Drag & Drop can limit your testability.

ChrisCY wrote:

Hi guys,

Thank you for your replies.

jmeckley wrote:

1. if you're using the LLBLDataSource, set the AdapterToUse property to retrieve an IDataAccessAdapter from the DataAccessAdapterFactory.

Using the demo version of LLBLGen, I can't find the AdapterToUse property of the control.

The control has the AdapterTypeName property which can't be hardcoded since I want it to refer to a different namespace in each deployment according to a configuration value (say from web.config).

I want this change to be configured before deployment. Once deployed the application will use only one database of the configured type.

Chris

AdapterTypeName is a property of LLBLGenProDataSource2, the adapter version of hte control. Did you use that one?

Well yes,

Since I want support for different database types, I need to use the adapter paradigm thus the LLBLGenProDataSource2 control, isn't it?

I played around by creating a class which implements IDataAccessAdapter and acts as a wrapper for the adapters generated automatically by LLBLGen. The constructor of the class, reads web.config and instantiates the correct type of the adapter, saving the instance to a private field. It then simply delegates every call to the respective method of this internal instance.

I put the class in App_Code and after building the website, I was able to see my custom Adapter in the list of the available adapters in the datasource configuration dialog box. But when I select the custom adapter the selection is not saved and the datasource is not being configured. If I type the class name manually at the source, the designer throws an exception on this control.

I tried to pack the custom adapter in a dll through a separate project but nothing changed.

The thing is, that when I instantiate my custom adapter in a C# file and manually retrieve a collection and bind it to a control, it works like a charm! But that's just the proven factory pattern.

Any thoughts?

Chris

PS I expect to have a licensed version of the software sometime next week (company paperwork!) so I hope I will be able to digg into it more seriously.

What happens if you used a class that inherits from the DataAccessAdapter?

If I type the class name manually at the source, the designer throws an exception on this control.

What was the exception?

Well the problem has strangely been fixed!

It used to say to me that he couldn't set the value 'SwitchDataAccessAdapter, App_Code' to the AdapterTypeName property. This was printed on the datasource 'box' in the designer, i.e. it couldn't render the control correctly. After successive attempts with and without the 'App_Code' part of the setting, it finally started working correctly.

It was probably a matter of the Designer being able to load the class correctly the first time!

Right now it seems to work ok, with full Designer support. I set a value in the form of 'SwitchDataAccessAdapter, App_Code.z3gjdnwd'. I don't know what the gibberish at the end mean but as long as it works!

Thank you for your time and effort.

Chris.