Are there plans to have LLBLGenLinq work with DynamicaData?

Seems like it just might work out of the gate?

Bryan

What do you mean with DynamicData exactly?

http://weblogs.asp.net/scottgu/archive/2007/12/14/new-asp-net-dynamic-data-support.aspx

It is a new Microsoft extenstion to ASP.net in beta at the moment.
Using a templates and a new set of controls, called dynamicadata controls, It takes a "LINQ to SQL" or "LINQ to Entity" data context and created crud screens.

I have already used it successfully in a RAD fashion. The approach would be to create the screens using DynamicaData, then customize them as you go. You can make an application very quickly.

It builds a framework or scaffolding, which is what they call it, that allows the programmer to customize it.

I am sure "LINQ to LLBLGen" would work. Guessing of course.

Bryan

By the look of it, it seems the support for linq to sql is hardcoded. this is because it also needs to save entities and that's not done through linq. Also, it seems that the meta-data is obtained by the code which can only be done if the code has access to the meta-data, thus knows what stuff it's dealing with.

Unless they create an interface for it, it's not going to work. Although I haven't heard much about this framework lately.

I know Microsoft has been working on it for a while. I remember a reference to this project a year ago. I just recently got myself into the beta for it so I will keep you posted, if I am allowed. I think I am. I don't think this is top secret, but I will check.

I used it on a small project and was able to blow out crud screens in 0 time obviously. It was nice to be able to get something to the client in hours instead of days. Then as time goes on I am replacing the functionality with a more traditional approach.

This really worked out well for me.

Bryan

BringerOD wrote:

I know Microsoft has been working on it for a while. I remember a reference to this project a year ago. I just recently got myself into the beta for it so I will keep you posted, if I am allowed. I think I am. I don't think this is top secret, but I will check.

I used it on a small project and was able to blow out crud screens in 0 time obviously. It was nice to be able to get something to the client in hours instead of days. Then as time goes on I am replacing the functionality with a more traditional approach.

This really worked out well for me.

Bryan

You can mail me, I'm under NDA of MS anyway, so all NDA stuff will stay NDA.

Anyway, is it really hardcoded to linq to sql? Or more flexible? (wasn't this project called 'Jasper' btw? )

Microsoft’s Dynamic Data reads attributes on the partial classes to change its behavior. It can change the description of fields, add validation, range checking, etc. It has a similar feel to the Validation Application Block. It reads the relationships that where described by the foreign keys created in the designer and uses them to link the screens together. The team at Microsoft calls it scaffolding!

Through attributes and LINQ to SQL I believe it could do all it needed. That was why I asked the question here. I would prefer to use “LINQ to LLBLGen”. I am not sure if I am qualified to make the final assessment.

Also I do know this works with “LINQ to Entities” which will work with ADO.NET and other DBMS, not just SQL SERVER. This would suggest that “LINQ to LLBLGen” is possible. Again I am not sure.

Also a nice feature is you can replace the default edit and view controls. For example, you can make your own text edit control that works within their framework that creates a freetextbox control. Very nice plug and play features. You set the default and then you can be more specific on each page and override the default behavior. Again this makes developing application incredibly fast. You basically get data entry screens for everything. Then you can slowly override the functionality.

Hmm. Well, the selects etc. can be done using IQueryable, the updates etc. is another story. I know from Astoria that it requires an interface for updates/deletes, and that's logical. What I think will happen is that they'll use the same thing for this as well (that would be the easiest )

So what's important is to know what's required to make our code work with their code. I.e.: which interfaces are to be implemented by the generated code (which implementation can be generated ofcourse).

Otis,

I've been using LLBLGenPro for about 2 years and really like your product!

I also like what I have seen so far in MS' Data Dynamic controls preview. I think it (or something evolved from it) will become the de facto way of developing data entry asp.net apps within 12-18 months. Combined with LINQ, I wonder if this might be a disruptive 'technology' that hurts LLBLGen.

From Scott Hanselman's blog (http://www.hanselman.com/blog/PuttingASPNETDynamicDataIntoContext.aspx) it appears that an I/F between Dynamic Data controls and ORMs might appear in the next version. Sure would be great if you could work with the MS people to make sure that interfacing with LLBLGenPro-generated ORM code will be possible sooner rather than later. And also to make sure that the I/F is designed in such a way to take advantage of LLBLGenPro features instead of a competitor's.

Emmanuel wrote:

Otis,

I've been using LLBLGenPro for about 2 years and really like your product!

I also like what I have seen so far in MS' Data Dynamic controls preview. I think it (or something evolved from it) will become the de facto way of developing data entry asp.net apps within 12-18 months. Combined with LINQ, I wonder if this might be a disruptive 'technology' that hurts LLBLGen.

We're working closely with Microsoft at the moment to see how DynamicData can be connected to LLBLGen Pro. With a private build we have it working except 2 key areas which is related to how they provide filtering parameters to datasource controls and how they determine fk field values. Both problems could be solved by MS, but it's undecided yet if they want to proceed at this point (the classes we use are internal in the public build). So IF they proceed, DynamicData is usable with llblgen pro when it is released, however if they decide to postpone the extensibility, they'll add extensibility to v2, they said (which isn't far off)

Dynamic data is ok, though it's not something mind blowing which will change the landscape. For example, it lacks m:n and 1:1 relation support, and has some other areas where things need to get more body. It's a nice direction and I'm sure, if not with v1, dynamic data and llblgen pro will be connected in the (near) future

Glad to hear that you are plugged into this work. Gives me the confidence that I'm making the right choice by basing all my development around LLBLGen Pro.

Stick with LLBLGen. LINQ to SQL and LINQ to Entities have a long way to go in many areas. In my opinion they should beg Frans Bouma to sell him his company to them.

I blogged about this recently. http://bryan.reynoldslive.com/post/Dynamic-Data---New-Code-Drop.aspx

To summarize, DynamicData is not the answer to all things.

Bryan

BringerOD wrote:

Stick with LLBLGen. LINQ to SQL and LINQ to Entities have a long way to go in many areas. In my opinion they should beg Frans Bouma to sell him his company to them.

Well, who knows what they'll do but up till now they're pretty much living in NIH land

Dynamic data is ok, though it's not something mind blowing which will change the landscape. For example, it lacks m:n and 1:1 relation support, and has some other areas where things need to get more body.

I certainly agree that its not mind blowing. But I do think its a quick and easy way to get things started on a web project. I never considered what Dynamic Data creates as "final"; but simply a starting point to get a project done. My two cents.

We received a new drop of code. It helps fixing the two roadblocks. We're not there yet, but getting closer

So, what's the status on DynamicData?

It looks really interesting.

Thanks,

Fishy

It's available for a while now (see v2.6 download section, or main site download section )

I guess I should've investigated a little further.

Thanks for all your hard work!

Hello. I might be missing something in this discussion. When Otis says that LINQ to LLBLGen Pro works with DynamicData, it sounds like I should be able to create a DynamicData web site, point it to my LLBLGen Pro generated classes, and get a dynamically created CRUD site, but I can't figure out how to do that. (Note that I'm an LLBLGen newbie--I just downloaded the demo today. I'm not a newbie developer, though. I'm an oldie developer.)

Here's what I tried:

1. Point LLBLGen to a DB2 for Windows sample database running on my development machine and generate classes.
2. Reference the generated project in a test app.
3. Verify that I can use LINQ syntax to read from the LLBLGen-generated class model. Eg:

// This works.
LinqMetaData metaData = new LinqMetaData();
var acts = from act in metaData.Act select act;
foreach (var act in acts)
    Console.WriteLine(act.Actno);

1. Create a new Dynamic Data Entities Web Site and set a reference to my LLBLGen-generated project.
2. In Global.asax, specify the fully qualified name of my LinqMetaData class in the call to RegisterContext, and specify ScaffoldAllTables = true.
3. Run the web site project.

This throws a System.Argument exception with the message, "The context type 'Llblgen1.Linq.LinqMetaData' is not supported." Thus the type is found, but evidently is not what is meant to be there. (Yes, I was grasping at straws.)

So, can this be done, and can you point me in the right direction?

Thanks for any help!

Dave

Well, kind of. You have to create a LLBLGen Pro Dynamic Data site. There is a project template for it that is distributed on the dowload page.

Thanks! I downloaded the template and followed the instructions in the readme, and all was good.

Another question. My test was was on a machine that has DB2 Connect 9. Does anyone know whether I should be able to do the same thing on a machine that has version 8?

Thanks for any info!

Dave

Thanks! I downloaded the template and followed the instructions in the readme, and all was good.

Another question. My test was was on a machine that has DB2 9 for Windows. Does anyone know whether I should be able to do the same thing on a machine that has version 8?

Thanks for any info!

Dave

As LLBLGenPro supports both DB2 version, the tests should works as well.

David, thanks for the reply.

That doesn't seem necessarily true, though. LLBLGen's support for LINQ or Dynamic Data when hitting a DB2 database could reasonably depend on support found only in IBM's V9 driver. This is in fact the case when using IBM's version of LINQ to DB2--version 9 is required. That's the reason I'm investigating LLBLGen--I would like to build a Dynamic Data site against a DB2 V8 database. Does anyone know for a fact that this is possible? Has anyone in this forum done it?

Thanks again.

Dave

Actually, it looks like this isn't possible. SD.LLBLGen.Pro.DQE.DB2.NET20.dll contains a specific version reference to "IBM.Data.DB2, Version=9.0.0.2, Culture=neutral, PublicKeyToken=7c307b91aa13d208". Thus version 9 of DB2 appears to be required. Since my organization isn't moving to version 9 until next year, it looks like my investigation into LLBLGen is over unless someone from Solutions Design can provide guidance on how to do this.

Thanks for the responses!

Dave