Hi, I work at an ISV an am evaluating O/R mapping systems with a view to us using one to develop our next application.

I have currently tried three flavours... LLBLGen, NHibernate and DevExpress Persistent Objects.

The first two seem to be the most mature, and the easiest to map onto legacy databases (something I may need to do).

There is one major problem I don't seem to be able to resolve with LLBLGen:

We develop Winforms Applications (delivered via Click-Once). Owing to heterogeneous nature of our client's database environments, to firewall issues and to other security/politic-related issues, we cannot have the client connecting directly to the database.

Our intention is to use WCF (or remoting if we have to) as the channel for data, whilst still utilising the performance benefits of the o/r system (i.e. client-based object caching, lazy loading etc.) This way the server can be configured to talk to the database and the client only needs to know of the server's endpoint.

At the moment, the only direct support I can see for this architecture is with the (otherwise inferior) DevExpress XPO - it allows one to remote an IDataStore that is designed to abstract the base operations of reading/writing data, whilst keeping the O/R logic on the client.

I am really hoping I've missed something with LLBLGen... and would welcome some example code to confirm that I can achieve the same effect with this product.

Thanks, Mark.

Hi,

you can use WCF with llblgen and you could ifnd many posts about it on the forum. The best way is to use adapter and not selfservice scenario for the wcf or remoting. What problem do you have with it, what test do you try to do?

Ok, this is good news.

So, using the Adapter Template Group, are you able to tell me (or point me to the relevant forum post) the recommended to remote the retrieval of data whilst keeping the cache of objects on the client?

Many thanks, Mark.

Hi again - I have just come across this posting which doesn't bode well for me:

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7638&HighLight=1

It would appear the Lazy loading and client-side caching are not supported when in adapter mode.

These are two of the predominant requirements I have for an o/r mapping system.

So, if you are saying I should not use the SelfService model over WCF, then I suppose this product is not for me?

markalroberts4 wrote:

Hi again - I have just come across this posting which doesn't bode well for me:

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7638&HighLight=1

It would appear the Lazy loading and client-side caching are not supported when in adapter mode.

These are two of the predominant requirements I have for an o/r mapping system.

So, if you are saying I should not use the SelfService model over WCF, then I suppose this product is not for me?

Please understand the following: When you send a selfservicing entity, say customer, over the wire to the client via WCF and in the client you do: OrderCollection col = customer.Orders;

what will happen? -> the lazy loading will be triggered but as you're on the client, it doesn't know anything about the db. This thus will fail.

Also, if you call for example Save() on the entity on the client, it will fail, as the db isn't there but on the service.

That's why selfservicing isn't suitable for distributed scenario's.

'Client side caching'.. in a distributed scenario: do you mean caching on the client or in the service ? Please read my article about caching

You should cache processing results, so fragments of webpages for example, not resultsets.

Please check Frans' post on the following thread (the last post): http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=9344

(that's a helpdesk thread, so others can't see it -- Otis)

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=9344 points nowhere.

I have read the very well written aricle about whether o/r caching is a such a good idea, and can very much see the point.

I would like to have the option to cache sets of objects for filtering/viewing/sorting of the UI, as I currently do in my strongly typed datasets.

It would appear that using the adapater model in LLBLGen, that I have to do this myself?

Mark.

markalroberts4 wrote:

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=9344 points nowhere.

I have read the very well written aricle about whether o/r caching is a such a good idea, and can very much see the point.

I would like to have the option to cache sets of objects for filtering/viewing/sorting of the UI, as I currently do in my strongly typed datasets.

Oh but you can. Entity collections could be used as such and you can use entityview objects created from them which you can filter, sort, project to a new set etc. in memory , completely on the client. This is supported in both paradigms.

Otis wrote:

Please understand the following: When you send a selfservicing entity, say customer, over the wire to the client via WCF and in the client you do: OrderCollection col = customer.Orders;

what will happen? -> the lazy loading will be triggered but as you're on the client, it doesn't know anything about the db. This thus will fail.

Also, if you call for example Save() on the entity on the client, it will fail, as the db isn't there but on the service.

Yes, it would appear to for this product. I hope you don't mind me linking to documentation for another product

http://community.devexpress.com/blogs/xpo/archive/2006/04/13/41.aspx

but the diagram there shows pretty well how they have got around the problem by abstracting the "IDataStore" to the server, so when the Save() on the client is called, it does know about the database (but the specifics of which falvour of database and what connection string are in a proxy on the server)

markalroberts4 wrote:

Otis wrote:

Please understand the following: When you send a selfservicing entity, say customer, over the wire to the client via WCF and in the client you do: OrderCollection col = customer.Orders;

what will happen? -> the lazy loading will be triggered but as you're on the client, it doesn't know anything about the db. This thus will fail.

Also, if you call for example Save() on the entity on the client, it will fail, as the db isn't there but on the service.

Yes, it would appear to for this product. I hope you don't mind me linking to documentation for another product

http://community.devexpress.com/blogs/xpo/archive/2006/04/13/41.aspx

but the diagram there shows pretty well how they have got around the problem by abstracting the "IDataStore" to the server, so when the Save() on the client is called, it does know about the database (but the specifics of which falvour of database and what connection string are in a proxy on the server)

Oh, sure, but then the service and client have to use the same transport layer they provide. With our code, you're free how to build your service and client, as it should.

For example with custom sinks, your API exposed as a true SOA service, like you should, instead of working with the API provided by the datastore (at least thats how I see it, haven't studied their model in detail).

Anyway, selfservicing's features aren't available to you on the client in our case. I'd like to add that you should realize that if you need a service that's placed at such a low-level in your application stack, why DO you need it as a service in the first place? SOA isn't meant for that as it creates a lot of overhead for practically not much value (as the service has no real point other than being a low-level tier in an app, it doesn't have its own interface and can't work on its own as an autonome app, as it should)

Otis wrote:

With our code, you're free how to build your service and client

I would really value knowing how and why I would wish to do this?

Otis wrote:

Anyway, selfservicing's features aren't available to you on the client in our case. I'd like to add that you should realize that if you need a service that's placed at such a low-level in your application stack, why DO you need it as a service in the first place?

We are an ISV that produce enterprise software that works with either Oracle or MSSQL server. We need to produce WinForms clients owing to the superior flexibility and power the provide over ASP.Net apps. We need to have cached data on the client for modelling purposes.

The main reason why we cannot talk straight to the database is the institutions we target tend to have strict rules in place (and politics is a big showstopper!) about exactly which applications can communicate with the DB. There are often firewalls in place too. We need to have a server-side application talk to the database pass data as efficiently as possible to the client, which does not have a connection string or any security related details - just a WCF endpoint, which we are able to configure as we wish since we are supplying the software.

I would love to be able to talk the database directly and use the self-service LLBLGen or NHibernate. Unfortunately this is not an option

markalroberts4 wrote:

Otis wrote:

With our code, you're free how to build your service and client

I would really value knowing how and why I would wish to do this?

Don't you want to be in control of the API of your service and the way the client connects to the service? Personally I would like to be in control of that.

markalroberts4 wrote:

Otis wrote:

Anyway, selfservicing's features aren't available to you on the client in our case. I'd like to add that you should realize that if you need a service that's placed at such a low-level in your application stack, why DO you need it as a service in the first place?

We are an ISV that produce enterprise software that works with either Oracle or MSSQL server. We need to produce WinForms clients owing to the superior flexibility and power the provide over ASP.Net apps. We need to have cached data on the client for modelling purposes.

The main reason why we cannot talk straight to the database is the institutions we target tend to have strict rules in place (and politics is a big showstopper!) about exactly which applications can communicate with the DB. There are often firewalls in place too. We need to have a server-side application talk to the database pass data as efficiently as possible to the client, which does not have a connection string or any security related details - just a WCF endpoint, which we are able to configure as we wish since we are supplying the software.

I would love to be able to talk the database directly and use the self-service LLBLGen or NHibernate. Unfortunately this is not an option

I see, that's indeed a scenario where using a service is an option, though you can of course design the service as different as you might want.

What you're suggesting is that the service is basicly a frontend to the DB and acts upon what you send to it for db access command. You could also opt for a higher level service which has more logic on the service and exposes an interface where the client is thus much dumber: it then calls service methods to get things done, the client itself has no clue what to do with the data, it just sends it along to the service to get a given action done, or asks the service for a particular set of data by calling a method and passing some parameter (for example).

This latter setup is more flexible for the logic, as how things are processed etc. isn't on the client so if things change you don't always have to update the client. The former is easier to write, though is also pretty 'chatty' (or can be 'chatty') and less performant, as you probably will pull more data over the wire than anticipated.

Otis wrote:

What you're suggesting is that the service is basicly a frontend to the DB and acts upon what you send to it for db access command.

I know this is not a method you suggest to use, but I suppose it would be pretty straightforward to implement a wrapper for DataAccessAdapter which inherits from MarshalByRefObject and then use llblgen as db front end. When talking about remoting that is. I guess it should be doable with WCF as well.

I myself would go with Otis's suggestion of using properly defined services though

Thanks for all the replies. I take you points, but would say that "properly defined services" in my case would be services that facilitate the creation of large collections of objects that are cached locally and then handle their own data scoping. The application we are writing is very complex and objects are used in a multitude of ways not lending themselves a few rigid contract methods in a WCF channel.

markalroberts4 wrote:

Thanks for all the replies. I take you points, but would say that "properly defined services" in my case would be services that facilitate the creation of large collections of objects that are cached locally and then handle their own data scoping. The application we are writing is very complex and objects are used in a multitude of ways not lending themselves a few rigid contract methods in a WCF channel.

You'll run into performance problems because of that, no matter what you choose, because of the large amount of data you'll be transporting over the wire.

Also, you then cache the data locally anyway, why not cache the data locally in a db? replicated from the main db?

You'll run into a problem which is plaguing many SOA apps simply because SOA isn't meant for these kind of architectures: the service is placed at a low level in the app: the service is hammered a lot by clients because of the chatty nature and a LOT of data is pulled over the wire (think in thousands or hundreds of thousands of entities), which makes the service layer a BIG bottleneck in the complete application.

You'll run into performance problems because of that, no matter what you choose, because of the large amount of data you'll be transporting over the wire.

This is true, however, you might reduce some of the problems by using compression features that exists on web server. I guess there is a trade off - compression overhead v large data on the wire.

Also, you then cache the data locally anyway, why not cache the data locally in a db? replicated from the main db?

Your firewall people might have a problem with this I guess, hence you are looking for SOA type architecture.

You might wan to consider use of DTO (search MSDN and this forum). This might give you temporary 'caching' (overhead, additional memory), and also make it less chatty.