Hey folks,

yesterday I saw a thread at the MagicAjax forum that with the upcoming of Atlas the projects leader struggles with lack of community support and therefore he want´s to quit the project. I like MagicAjax very much but that seems to be the reality with open source software their capital is a vital community which contributes their time and skills! If it lacks like with real capital(money) a company is going to die! Luckily our beloved codegenerator is not open-source and will be supported as long there are clients which pay for the product!

But the reason for this thread is that I would like to take the time and ask you what could be the future of LLBLGen (I see DLINQ good 3 years away but when it comes LLBLGen should be prepared)

What are your ideas, what features could be added to LLBLGen in the future?!

Here are my ideas:

L(ower)L(evel)B(ussiness)L(ayer)Gen goes B(usiness)L(ayer)Gen

a. adding new features to the designer/template studio - like adding business rules in the designer to fields and entities - making a real workbench out of templatestudio with auto complete etc.

b. incorporating business frameworks - (JCL is a very good start!) - maybe also spring.net - maybe something like DevExpress is offering in their CTP

c. adding generation of GUI elements I am dreaming of a completely generated (entity)component which I can drag on my webform like in MS Access with two-way databinding of course!

What are your ideas?

adrianporger wrote:

Hey folks,

yesterday I saw a thread at the MagicAjax forum that with the upcoming of Atlas the projects leader struggles with lack of community support and therefore he want´s to quit the project. I like MagicAjax very much but that seems to be the reality with open source software their capital is a vital community which contributes their time and skills! If it lacks like with real capital(money) a company is going to die! Luckily our beloved codegenerator is not open-source and will be supported as long there are clients which pay for the product!

And some time after that, as we're a healthy company

But the reason for this thread is that I would like to take the time and ask you what could be the future of LLBLGen (I see DLINQ good 3 years away but when it comes LLBLGen should be prepared)

DLinq will be here in H2 of 2007, or at least something which talks to the DB using Linq and which is MS made. There were some documents posted about ADO.NET 3.0 a week ago, but these were removed a day after that, however luckily I read them and we now know what we have to do to stay ahead

What are your ideas, what features could be added to LLBLGen in the future?!

Well, it's obvious that we won't disclose what we'll do, but we have made a plan to bring it to the next level in v3 (for 2007), which has something to do with Linq obviously.

Here are my ideas:

L(ower)L(evel)B(ussiness)L(ayer)Gen goes B(usiness)L(ayer)Gen

hehe Well, one golden rule of marketing you should never forget: never change the name of a well known product.

a. adding new features to the designer/template studio - like adding business rules in the designer to fields and entities - making a real workbench out of templatestudio with auto complete etc.

Option 2 is planned for 2006 and v2 of llblgen pro. Though I don't think the market is in the template editing, as with DSL tools, you'll have the editor in the form of nice models, and a template generator below it.

b. incorporating business frameworks - (JCL is a very good start!) - maybe also spring.net - maybe something like DevExpress is offering in their CTP

Business logic is obviously becoming very important, now the hurdle of getting the data into workable objects is taken. DevExpress' toolkit is targeted at gui -oriented programming. While appealing, it doesn't work in larger development teams and projects (IMHO), though something else does, though I can't disclose that yet

c. adding generation of GUI elements I am dreaming of a completely generated (entity)component which I can drag on my webform like in MS Access with two-way databinding of course!

2-way databinding clicketyclick development is already possible with v2 (now in beta ).

Ha Frans,

Any ideas why MS removed the link to the ADO 3.0 documents ? I was definitely interested in MS's view on the future of ADO and ORM-functionality......and of course your opinion about their view :-)

Regards, Danny

"clicketyclick [..]" LOL!!!

for collections yes but for single entities???

adrianporger wrote:

"clicketyclick [..]" LOL!!!

for collections yes but for single entities???

Yes, look at the DetailView and FormView controls in ASP.Net. Winforms DB supports drag-n-drop binding also.

BOb

DvK wrote:

Ha Frans,

Any ideas why MS removed the link to the ADO 3.0 documents ? I was definitely interested in MS's view on the future of ADO and ORM-functionality......and of course your opinion about their view :-) Regards, Danny

I have no idea why they removed them, I asked them about it but they simply ignored it and instead said they stuff will be back 'soon'... I have the feeling someone got upset that they now have 2 techniques: DLinq and ado.net 3.0 and it will confuse everyone because after you've seen ado.net 3.0, you will wonder why you even would need DLinq.

I can't see DLinq causing LLBLGen to lose out, I will still want something to generate my queries for me, I personally can't stand using SQL, so having SQL like statements in code just puts the fear of god in me.

As for suggestions for future improvements, well, Spec# is coming on nicely now, although probably not quite ready enough to dedicate a serious amount of time to. Where you can do Eiffel style design-by-contract in C# (well, their variant of C#). It would be good if you could specify the contracts for each entity/typed-list/parameter etc from LLBLGen in a nice GUI way.

Obviously that's a way off, but I definitely think a visual designer for business rules is generally a good thing (as long as you can represent all of your rules ).

louthy wrote:

I can't see DLinq causing LLBLGen to lose out, I will still want something to generate my queries for me, I personally can't stand using SQL, so having SQL like statements in code just puts the fear of god in me.

DLinq will be able to do that for you too, but not everything. For example TargetPerEntity inheritance isn't possible with dlinq.

As for suggestions for future improvements, well, Spec# is coming on nicely now, although probably not quite ready enough to dedicate a serious amount of time to. Where you can do Eiffel style design-by-contract in C# (well, their variant of C#). It would be good if you could specify the contracts for each entity/typed-list/parameter etc from LLBLGen in a nice GUI way.

You don't want to specify it in code? I thought about defining rules in a designer, but it would take way more time to define them in a designer than by simply write them out in code/text.

Otis wrote:

louthy wrote:

As for suggestions for future improvements, well, Spec# is coming on nicely now, although probably not quite ready enough to dedicate a serious amount of time to. Where you can do Eiffel style design-by-contract in C# (well, their variant of C#). It would be good if you could specify the contracts for each entity/typed-list/parameter etc from LLBLGen in a nice GUI way.

You don't want to specify it in code? I thought about defining rules in a designer, but it would take way more time to define them in a designer than by simply write them out in code/text.

I may have just been thinking out loud there Maybe a system similar to the WebForm designer where you click on a button and it takes you to the code for the button click. So you'd click on a property in LLBLGen and be taken to an overloaded property definition.

Again thinking out loud, just woken up etc.

louthy wrote:

Otis wrote:

louthy wrote:

As for suggestions for future improvements, well, Spec# is coming on nicely now, although probably not quite ready enough to dedicate a serious amount of time to. Where you can do Eiffel style design-by-contract in C# (well, their variant of C#). It would be good if you could specify the contracts for each entity/typed-list/parameter etc from LLBLGen in a nice GUI way.

You don't want to specify it in code? I thought about defining rules in a designer, but it would take way more time to define them in a designer than by simply write them out in code/text.

I may have just been thinking out loud there Maybe a system similar to the WebForm designer where you click on a button and it takes you to the code for the button click. So you'd click on a property in LLBLGen and be taken to an overloaded property definition.

Again thinking out loud, just woken up etc.

heh

Well, when DSL's are more mainstream, and the tools are somewhat more mature (MS' DSL kit) BL rules are a good candidate for a DSL, but it's a completely different ballgame altogether though, those BL rule engines

Docs are up again... http://weblogs.asp.net/fmarguerie/archive/2006/06/17/ADO.NET-vNext-Entity-Framework-documents.aspx

I took a quick overview of the "Next Generation Data Access June 2006.doc" but I can´t find anything revoluntionary in it !

Look at Chapter 8 looks dam close to what CoolJ can offfer today! What do you think?

1. Entity Framework Architecture

This section briefly describes the architecture of the Entity Framework being built as part of ADO.NET. A detailed description of the architecture can be found in [ARCH]. The main functional components of the ADO.NET Entity Framework (see Figure 1) are: Data source-specific providers. The Entity Framework builds on the ADO.NET data provider model. SqlClient is the storage-specific provider for the Microsoft SQL Server database products including SQL Server 2000 and SQL Server 2005. WCFClient is a future provider to enable access to data from Web Services. In terms of interfaces, the ADO.NET provider model contains Connection, Command, and DataReader objects. A new SqlGen service in the Bridge (mentioned below) generates store-specific SQL text from canonical commands. Map provider. The Entity Framework includes a new data provider, the Map provider. This provider houses the services implementing the mapping transformation from conceptual to logical constructs. The Map provider represents a value-based, client-side view runtime where data is accessed in terms of EDM entities and relationships and queried using the eSQL language. The Map provider includes the following services: EDM/eSQL. The Map provider processes and exposes data in terms of the EDM values. Queries and updates are formulated using an entity-based SQL language called eSQL. Mapping. View mapping, one of the key services of the Map provider, is the subsystem that implements bidirectional views that allow applications to manipulate data in terms of entities and relationships rather than rows and tables. The mapping from tables to entities is specified declaratively through a mapping definition language. Query and update pipelines. Queries and update requests are specified to the Map provider via its Command object either as eSQL text or as canonical command trees. Store-specific bridge. The bridge component is a service that supports the query execution capabilities of the query pipeline. The bridge takes a command tree as input and produces an equivalent command tree (or command trees) in terms of query capabilities supported by the underlying store as output. Metadata services. The metadata service supports all metadata discovery activities of the components running inside the Map provider. All metadata associated with EDM concepts (entities, relationships, entitysets, relationshipsets), store concepts (tables, columns, constraints), and mapping concepts are exposed via metadata interfaces. The metadata services component also serves as a link between the domain modeling tools which support model-driven application design. Transactions. The Map provider integrates with the transactional capabilities of the underlying stores. API. The API of the Map provider follows the ADO.NET provider model based on Connection, Command, and DataReader objects. Like other store-specific providers, the Map provider accepts commands in the form of eSQL text or canonical trees. The results of commands are returned as DataReader objects Occasionally Connected Components. The Entity Framework enhances the well established disconnected programming model introduced by the ADO.NET DataSet. In addition to enhancing the programming experiences around the typed and un-typed DataSets, the Entity Framework embraces the EDM to provide rich disconnected experiences around cached collections of entities and entitysets.

Yes there's nothing revolutionairy in it, except that it can create a virtual entity layer on top of a schema, which is IMHO a step forwards, but for the rest, it's same old same old. We've still one year to go to implement our next step so we'll stay ahead of them

(they work with 150+ people on this, let's see if we can outsmart them all )

they work with 150+ people on this, let's see if we can outsmart them all )

Well be careful! Last time I visited Scott´s blog he referred to LLBLGen... "big brother is watching you!"

All the best

Adrian

adrianporger wrote:

they work with 150+ people on this, let's see if we can outsmart them all )

Well be careful! Last time I visited Scott´s blog he referred to LLBLGen... "big brother is watching you!"

heh . Yeah I know, but Scott is one of the nicest guys I've ever met, he's just a true geek who loves cool code, whoever it wrote it doesn't matter.