Hi Frans;

Since you know everything I'd like to know if your product line will work for the new SL 2, where the client needs to connect to a middle tier service to get/set data (where the middle tier would perform the task of connecting to database and performing data service)?

MSFT is working on ADO.Net Data Service (Asoria) which uses EF as it's data modeling and they recommend to use this as the middle tier data service. I think for SL apps this is an overkill of building a large middle tier.

My question is, will you have a solution that can work as the middle tier between a Sl Client using LINQ to talk to your data service and your product can then deliver the data in a fashion that the client can use it?

I hope you can shed some light on this! Thanks!

Using linq in a silverlight client is overkill, as linq expressions aren't serializable so you have to go through hoops to get the query across the wire. It's better to have a service which exposes methods which you can call. This is really SOA best practise, please check Gregor Hohpe's (works at google) presentations about this on infoq.com

There's been some discussion about silverlight and llblgen lately, please check this thread: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=12698

In short: if it's easy to make an ORMSupportClasses dll for silverlight, we'll do it. If it takes a lot of work, maybe not. It's too early to say anything about that, as silverlights .net framework is pretty tiny (no system.data etc.) so it could give some problems here and there in our entities, and as microsoft makes changes to api's often during beta1 it's better to wait for beta 2 before looking into porting code over.

Otherwise, you should use DTO classes which you fill with llblgen code on the service.

Ok Frans, I'll to do more research during Beta 1 (especialy about System.Data) and keep you informed. As far as using LINQ on the client side, I probably failed to express myself properly. Once the data (in the form of XML) gets to client, then on the client I'll use LINQtoXML to do the Data manupulation. However, to get the data from the middle tier, there propbaly has to be a special syntax via URI to talk to the middle server to request or post data, without actualy sending the full LINQ expression, that's something Astoria does.

So, do you forsee that LLBL will eventualy have a middle tier data service module?

Thanks!

At the moment we don't have plans to come up with an Astoria variant, we're waiting what MS finds out in their usage tests. If that turns out to be successful, we will look into it, but not at the moment.

However, writing a service which produces entities in XML format is doable today already, and our XML serializer produces very compact XML so it's easy to consume that on the client with Linq to XML into objects you can handle on the client.

Otis wrote:

writing a service which produces entities in XML format is doable today already, and our XML serializer produces very compact XML

Frans; This line above, are you saying we can use LLBL inside of a middle tier WFC service to act as our database layer?

Thanks!

Yes, see our WCF example on the website

Otis wrote:

Yes, see our WCF example on the website

And then I can use (at middle tier) LLBL & LINQ to getr/set my data from database and then LLBL would generate the xml and then use WCF to send it to SL application and then within SL and LINQtoXML (as SL side), I can do my data manupulations???

If so, I then need to find out that any changes that are made to SL data that is send to Middle tier needs to be track on the middle tier side as well, for database concurrency. Secondly, I then need to find a away to talk to the middle tier for database operations (add, edit, delete, filter, sort, fetch a single record, or a group of records and etc.).

Am I onthe right track?

Yes.

Change tracking can be stored inside the XML, see the manual about this (adapter, distributed systems). When you then use the XML to deserialize the entities, changes to track are automatically in the entity and you can persist them.

I wouldn't go for a chatty service which exposes add/remove etc. though would go more for a higher-end service which is an application on its own but has no visible UI.

Otis wrote:

Yes.

Change tracking can be stored inside the XML, see the manual about this (adapter, distributed systems). When you then use the XML to deserialize the entities, changes to track are automatically in the entity and you can persist them.

I wouldn't go for a chatty service which exposes add/remove etc. though would go more for a higher-end service which is an application on its own but has no visible UI.

Frans, I'd like to revisit this discussion again, since some time has passed and hopefully it has given you a better picture about the two technologies, Silverlight and ADO.Net Data Services (Astoria).

As I'm pretty sure you're aware that Silverlight by itself has not way of connecting to any data source on it's own and requires to be fed by some sort of Web service. So, Microsoft has been been busy creating this service (Astoria) which it's main purpose is to expose data and handle the communication and serialization. But it uses a different technology to get to data (EF).

So, in our previous discussions, we talked about using WCF for and LLBLGen to basically create another Astoria, and the more I looked at it's depth and scenarios that involves, I decided to let MSFT do it than me.

Although, I see Astoria is fairly tight to EF to communicate with, but I also read that Astoria should be able to talk to other ORM systems for it's data. I think Astoria will do a perfect job to make your product as a 3-tier ORM solution for other clients, like WPF, AJAX, Flash, Silverlight, Winform and etc.

To make the long story short, are you looking into getting your product working with Astoria? Hopefully, you would shed some light on this please!

Thanks!

Yes, we've planned to ship Astoria support for LLBLGen Pro before SP1 RTM hits the streets later this summer.

Otis wrote:

Yes, we've planned to ship Astoria support for LLBLGen Pro before SP1 RTM hits the streets later this summer.

Excellent news! Are you planning to write a blog or some detail info how this will work with Astoria? Is it basically a replacement to the EF part?

Thanks and looking forward to knowing more about it. Been waiting too long ;-)

p.s. Frans, will there be a different version of your program to work with Astoria or the same product that you're selling right now for Winform and ASP?

Thanks!

BHayat wrote:

Otis wrote:

Yes, we've planned to ship Astoria support for LLBLGen Pro before SP1 RTM hits the streets later this summer.

Excellent news! Are you planning to write a blog or some detail info how this will work with Astoria? Is it basically a replacement to the EF part?

The ado.net dataservices require two things: a Queryable support part (which is done through our Linq support) and an implementation of their IUpdatable interface. That second part isn't done yet, though once we've added that you should be able to use llblgen pro as a replacement for EF with ado.net dataservices.

Thanks and looking forward to knowing more about it. Been waiting too long ;-)

p.s. Frans, will there be a different version of your program to work with Astoria or the same product that you're selling right now for Winform and ASP? Thanks!

It will be an add-on, freely downloadable, similar to the support of DynamicData which also will be an add-on, freely downloadable. Microsoft changed something in the api of dynamic data which requires SP1 beta at the moment, we'll correct that before Sp1 goes RTM as well.

Frans, ADO.Net Data Service (ADS for short), has different client programs (i.e. Silverlight, WPF, AJAX and etc) that communicate with the ADS server. Currently, for the Silverlight they have this EXE utility program to get the schema form the service and then build that for the client side, so on the client side, we can write LINQ statements, as if we were seeing the real entities. This raises two questions regarding using LLBL versus EF:

a) Does this utility create the client schema similar to what the EF schema was originally created on the service, meaning does mean, that client side has to follow/depend on what program was used to create server side services? if yes, wouldn't that pose a problem for you if the client side depends on EF?

b) One of the thing that bothered me about LinqToSQL, was the fact anytime you changed your database schema, you had to recreate your Linq2SQL schema again and there was no way to update/sync it. I'm not sure if EF has resolved this. However, adding the client layer, adds one more layer of abstraction that I have to worry about synchronization from Database to middle tier to client. Do we face the same problem with LLBL on the service side when the database schema changes? And if yours is automated, do we only have to worry about synching the client side to service side?

Thank you in advance!

Otis wrote:

Yes, we've planned to ship Astoria support for LLBLGen Pro before SP1 RTM hits the streets later this summer.

Is there any estimated release date for this?

Thanks in advance.

Not at the moment. We do consider it necessary to have an implementation soon, but how soon is not yet decided.