I just came to know about the upcoming ORM offering from MS called EDM. EDM is a resurection of Object Sapce. It will be part of ADO.NET 3.0 (currently named vNEXT) and will include language support for Entity SQL (eSQL) build on top of LINQ.

Reading about the architecture I found alot of similarities with LLBL.

The main difference being that EDM presists its model in an XML file. This XML file (the EDM) is what the application queries (using eSQL) instead of querying the DB. This also meens that the application becomes data-base agonistic as the EDM is single point of reference for the DB.

MS are adding alot of support for EDM into the upcoming ADO.NET. I wanted to see what everyone thinks about EDM as I see it directly competing with LLBL's offering.

Some resources about EDM screen-casts from the ADO.NET vNEXT's development lead: http://blogs.msdn.com/dataaccess/archive/2006/06/22/642260.aspx

The ADO.NET vNEXT CTP (August 2006) download link

The ADO.NET team blog http://blogs.msdn.com/adonet/archive/2006/08/15/701479.aspx

The features they'll include are for 100% already in llblgen pro and in a lot of the other O/R mappers. So we're not worried

Otis wrote:

The features they'll include are for 100% already in llblgen pro and in a lot of the other O/R mappers. So we're not worried

And are probably better implemented in LLBL**$##$ (one day I'll break my fingers typing it, I will reffer to LLBLGenPro as LL from now on :-)). Where I was, ah the implementation. Not sure what exactly is MS going to do but the template approach provided by LL is "the" way (I am afraid that MS won't let user play with their templates). Plus you get sources and better support with LL and a product that is evolving in shorter cycles. The only feature I am missing so far is Linq for LL which can't be provided at this time because Frans will have to wait for Linq RTM (C#/VB.NET compiler changes).

Agreed that LLBL covers all the intended features in EDM and I am 100% sure that EDM will not come close to LLBL's stability and maturity tell its second or third iteration.

The issue to consider her is that EDM is released as part of ADO.NET. Although architecture wise EDM is a layer on top of ADO.NET's data access objects, EDM does represent a strong case against why we would opt for a 3rd party framework when we have one build in. In addition, MS will add designer support for EDM similar to the VS.NET2005's DataSet designer. Also, I had an argument with one of the guys about the Pros/Cons of presisting the DB's schema in an XML file against presisting it in a code based DLL. I wonder if FRANS ever considered that in the early design stages of LLBL and if he did, why opt for the code-based approach over the XML one?

EDIT: The most interesting feature of the new EDM is Mapping. Mapping from tables to entities is specified declaratively through a mapping definition language and a designer tool in VS would facilitate the mapping graphically. The mapping subsystem allows applications to manipulate data in terms of entities and relationships rather than rows and tables. This meens that instead of modeling my entities as one-to-one to DB tables, I can model my entities and then map them to DB tables

omar wrote:

The issue to consider her is that EDM is released as part of ADO.NET. Although architecture wise EDM is a layer on top of ADO.NET's data access objects, EDM does represent a strong case against why we would opt for a 3rd party framework when we have one build in. In addition, MS will add designer support for EDM similar to the VS.NET2005's DataSet designer.

Well, what they have now for designer isn't that great to say the least . And I've to add 1 template to llblgen pro to add EDM support (which we'll do of course)

Also, I had an argument with one of the guys about the Pros/Cons of presisting the DB's schema in an XML file against presisting it in a code based DLL. I wonder if FRANS ever considered that in the early design stages of LLBL and if he did, why opt for the code-based approach over the XML one?

Well, the mappings have to be stored somewhere, and as LLBLGen Pro uses a designer, the mappings are stored there. I generate them into code because it's faster and the code can be transfered with the entity without having to access a central repository which contains the XML read data.

An external file has the disadvantage that you've to parse it at runtime, and cache the read data, otherwise you'll run into a performance hit. The caching of the data gives the problem that you have to centralize the mapping data, which isn't what you want if you want to work disconnected.

An external file is also another thing to deploy, but I don't find that a big disadvantage.

Attributes are another way to store mapping info, however these are very inflexible and also have the burden that you've to parse them first, cache the parsed data somewhere etc.

EDIT: The most interesting feature of the new EDM is Mapping. Mapping from tables to entities is specified declaratively through a mapping definition language and a designer tool in VS would facilitate the mapping graphically. The mapping subsystem allows applications to manipulate data in terms of entities and relationships rather than rows and tables. This meens that instead of modeling my entities as one-to-one to DB tables, I can model my entities and then map them to DB tables

That will be the same thing unless your DB tables are seriously badly designed. EDM offers indeed a way to define an abstract entity layer which mimics as if it's a database and you can map your entities onto these 'views'. Though for the rest, you can also do what they can do in LLBLGen Pro already for example with inheritance.

They offer mapping an entity on several tables without inheritance. This is perhaps nice at first, but will have severe drawbacks, for example when fetching data or when saving data. I'm not sure if they'll allow that in the final version.

V2.1 of LLBLGen Pro will have entities constructed from entities, thus aggregated entities, so you can have 'salesorder' which contains customer, order, orderlines etc. and define rules based on the 'salesorder' entity and threat it like a single entity.

With Designer Support??

So it will be possible to design "Business"-Entities right away in the designer?

and a BL RuleCollection where I can put my BL rules spanning multiple entities?

adrianporger wrote:

With Designer Support??

So it will be possible to design "Business"-Entities right away in the designer?

and a BL RuleCollection where I can put my BL rules spanning multiple entities?

That's the plan yes. And delay loaded fields

omar wrote:

I wonder if FRANS ever considered that in the early design stages of LLBL and if he did, why opt for the code-based approach over the XML one?

Slightly off-topic, but I've always felt that one of the huge advantages to NOT having an XML configuration is that you don't have to write unit tests for your basic persistence logic.

If you fat-finger your XML configuration code, you won't know that it doesn't work properly until you test it. So if you have a bug in your XML file in a non-obvious place (maybe an entity that isn't very important or isn't used often), it may go unnoticed without good unit test coverage.

If I save something with LLBL, I know that it will work, because it's functionality is a tested and proven feature of the framework.

Phil

Otis wrote:

V2.1 of LLBLGen Pro will have entities constructed from entities, thus aggregated entities, so you can have 'salesorder' which contains customer, order, orderlines etc. and define rules based on the 'salesorder' entity and threat it like a single entity.

Hey Otis,

When you have time, can you write a little about why you've decided to add this feature, where it's useful, etc.? I'm intrigued.

When is 2.1 planned?

psandler wrote:

Otis wrote:

V2.1 of LLBLGen Pro will have entities constructed from entities, thus aggregated entities, so you can have 'salesorder' which contains customer, order, orderlines etc. and define rules based on the 'salesorder' entity and threat it like a single entity.

When you have time, can you write a little about why you've decided to add this feature, where it's useful, etc.? I'm intrigued.

To have an edge over EDM, when it was first published. However now everything is abit more clear, EDM is actually less mature than I thought, but just in case

It's useful if you want to work in a routine with a single unit, of entities which semantically belong together in a given context. For example an Order and OrderLines are often a combination you want to use as one unit.

When is 2.1 planned?

The initial plan is Q1 2007, with a Linq supporting layer and EDM templates etc. after that.

I just think that its interesting that MS is actually acknowledging the fact that business / entity objects is the emerging trend.

One thing that is very funny is that for the past year I have been trying to get my EA team to buy into the idea of ORM as a way of writing applications. Maybe now that Microsoft is planning something formal and stating that entity objects is the direction that the market is shifting my EA team will have another look at LLBLGen.

It's indeed a big step, the paradigm shift. It has also surprised me how big they're going to push for this, as it will be a new layer into Sqlserver vNext, which effectively makes it an OODB.

But I'm glad MS finally will break open the market so the masses will learn about o/r mapping. It's funny to read on forums how people suddenly see the light because they've played with the Linq CTP or the ado.net vnext ctp, while there are tools on the market today which already offer that functionality for a loooong time

One the things that really caught my attention in the new EDM is how it exonerated (for the lack of a better word) LLBL and FARNS in the heated debate over the use of Dynamic-SQL over StoredProcedures. The new EDM generates dynamic parameterized SQL just as LLBLGen has been doing for some years!!

omar wrote:

just as LLBLGen has been doing for some years!!

First, a good new idea is ignored. As it gains some traction with a few people, the majority can no longer ignore it, so they laugh at it instead. As it continues to gain followers, this is no longer sufficient, so they attack it. Finally, they grudgingly accept it. You see the same process happen over and over again.

There will always be a few holdouts, though, right to the bitter end. There's some flaw in human nature that makes people irrationally resistant to changes in their view of the world.

.Net created the markets for Infragistics, Components One and Developers Express despite Visual Studio's own UI components. And while the "stock" UI components in VS remain stagnant, my DevEx components just get better and better. Same will be the case with LLBLGen vs ADO 3.0 ORM. People will research the ORM marketplace now that the technology is "endorsed" by MS and many will opt for a third-party implementation. Especially since LLBLGen licensing costs are so reasonable and the support is ledgendary.

Finally, and most importantly, there are so many productive and creative ways that an ORM tool can be enhanced and Frans can be much more agile and responsive than MS in that respect.

I'm totally confident that MS's offerings will raise the tide for everyone. This is a good thing for LBLLGen and its clientele.

Jeff

P.S. It may be a good time to update the "testimonials" section of your website.

Otis wrote:

It's indeed a big step, the paradigm shift. It has also surprised me how big they're going to push for this, as it will be a new layer into Sqlserver vNext, which effectively makes it an OODB.

But I'm glad MS finally will break open the market so the masses will learn about o/r mapping. It's funny to read on forums how people suddenly see the light because they've played with the Linq CTP or the ado.net vnext ctp, while there are tools on the market today which already offer that functionality for a loooong time

Jeff wrote:

.Net created the markets for Infragistics, Components One and Developers Express despite Visual Studio's own UI components. And while the "stock" UI components in VS remain stagnant, my DevEx components just get better and better. Same will be the case with LLBLGen vs ADO 3.0 ORM. People will research the ORM marketplace now that the technology is "endorsed" by MS and many will opt for a third-party implementation. Especially since LLBLGen licensing costs are so reasonable and the support is ledgendary.

Finally, and most importantly, there are so many productive and creative ways that an ORM tool can be enhanced and Frans can be much more agile and responsive than MS in that respect.

I'm totally confident that MS's offerings will raise the tide for everyone. This is a good thing for LBLLGen and its clientele.

I think so too. In the past years selling an o/r mapper was a 2-step story: first explain that O/R mapping is a great technique and THEN selling your own o/r mapper as the best in that field. That first step is getting easier and easier

P.S. It may be a good time to update the "testimonials" section of your website.

In what way? You want new ones?

Jeff wrote:

.Net created the markets for Infragistics, Components One and Developers Express despite Visual Studio's own UI components.

Well, I think there was a component/controls market well before .Net. VB really started it with it's support for ActiveX. Of course, initially you needed to create ActiveX controls in C++. Once you could create them in VB it really took off.

Actually, I think Dev Express started out making components and tools for Delphi. Code Rush was a Delphi tool first.

Anyway, I think the O/R market is always going to be camppy. Once Orcas comes out the combination of ADO.Net 3.0 and LINQ will become main stream so dynamic SQL won't be taboo and DBA's will have to accept it. Also, I think once it is "in the box" you might get a few more people looking for 3rd party stuff that is better. But, also, once O/R mapping and LINQ is in the box, 3rd party products will really have to find a way to stand apart or show how much more productive they are in order to win developer $'s.

There is a down side to using a 3rd party control in your app, and that is, every new developer you bring in needs to be trained on it. If you are using vanilla stuff, most devs are trained and ready to go.

BOb

pilotboba wrote:

Anyway, I think the O/R market is always going to be camppy. Once Orcas comes out the combination of ADO.Net 3.0 and LINQ will become main stream so dynamic SQL won't be taboo and DBA's will have to accept it. Also, I think once it is "in the box" you might get a few more people looking for 3rd party stuff that is better. But, also, once O/R mapping and LINQ is in the box, 3rd party products will really have to find a way to stand apart or show how much more productive they are in order to win developer $'s.

True, but that's already the case now: you've to proof that using o/r mapping is indeed better than using build-in datasets etc.

Looking at what MS is going to provide, I've no worries. We've a good set of plans for 2007 and I'm not worried at all that no-one or not a significant amount of people will stay interested in LLBLGen Pro.

There is a down side to using a 3rd party control in your app, and that is, every new developer you bring in needs to be trained on it. If you are using vanilla stuff, most devs are trained and ready to go.

That's indeed a good point. Because the plans for the designer for ADO.NET vNext and Linq for sql are really silly (imagine having 100+ entities on asingle canvas.. start saving money for that big fat machine now), we'll of course add templates for ADO.NET vNext / linq for sql.

Very little I have ever used from Microsoft is good enough out of the box that I didn't end up using some 3rd party technology to make it easier to deal with. Most of the time that I have tried to use Microsoft's stuff directly out of the box, I have ended up going down the path of "recreating the wheel" to build a usable framework out of it, which new developers would need to be trained on anyway, so why not just leave the heavy lifting to experts like Frans...

Otis wrote:

psandler wrote:

Otis wrote:

V2.1 of LLBLGen Pro will have entities constructed from entities, thus aggregated entities, so you can have 'salesorder' which contains customer, order, orderlines etc. and define rules based on the 'salesorder' entity and threat it like a single entity.

When you have time, can you write a little about why you've decided to add this feature, where it's useful, etc.? I'm intrigued.

To have an edge over EDM, when it was first published. However now everything is abit more clear, EDM is actually less mature than I thought, but just in case

It's useful if you want to work in a routine with a single unit, of entities which semantically belong together in a given context. For example an Order and OrderLines are often a combination you want to use as one unit.

When is 2.1 planned?

The initial plan is Q1 2007, with a Linq supporting layer and EDM templates etc. after that.

I can see these as being very useful as logical definitions of the subset of the domain model that a particular piece of code requires to operate on. Especially so if they can act as DTO's and intrinsically define a prefetch path. Frans, how do you see these being created? Built "Manually" from the constituent entities in code or automatically via their own fetch methods? Or both? I.e. do you see them as being "first class" citizens of the entity world or merely typed entity containers? I suspect there may be much value to be added here...

jaschag wrote:

Otis wrote:

psandler wrote:

Otis wrote:

V2.1 of LLBLGen Pro will have entities constructed from entities, thus aggregated entities, so you can have 'salesorder' which contains customer, order, orderlines etc. and define rules based on the 'salesorder' entity and threat it like a single entity.

When you have time, can you write a little about why you've decided to add this feature, where it's useful, etc.? I'm intrigued.

To have an edge over EDM, when it was first published. However now everything is abit more clear, EDM is actually less mature than I thought, but just in case

It's useful if you want to work in a routine with a single unit, of entities which semantically belong together in a given context. For example an Order and OrderLines are often a combination you want to use as one unit.

When is 2.1 planned?

The initial plan is Q1 2007, with a Linq supporting layer and EDM templates etc. after that.

I can see these as being very useful as logical definitions of the subset of the domain model that a particular piece of code requires to operate on. Especially so if they can act as DTO's and intrinsically define a prefetch path. Frans, how do you see these being created? Built "Manually" from the constituent entities in code or automatically via their own fetch methods? Or both? I.e. do you see them as being "first class" citizens of the entity world or merely typed entity containers? I suspect there may be much value to be added here...

Internally we had a debate about this: should we add a different type of element, like 'Business Component' which are elements build from entities, or should be introduce the ability to create an entity just like any other entity but it's not mapped onto a table but build from other entities in the system.

It's not settled yet, I lean towards the latter, but Ive to check how it works in practise.

they're units so if you fetch them, you'll be able to specify what to fetch. This is a tough problem to solve, performance wise, as fetching these entities in a hierarchy requires sub-prefetch paths (per hierarchy node) as well, so it might be that the feature looks nice on paper but in practise not a lot of people will use them in depth.

The core purpose of these entities is that you can treat a group of entity types as a single unit, like 'sales order' which has a reference to 'customer', order, order items and for example the employee who logged the order. I don't see them play a large part in extensive fetch scenario's, like lists of data, as it's more efficient to use dyn. lists or typed lists for that. However for managing data they can be helpful, also because you can add validation for a single unit so validation and BL rules are simpler.

otis wrote:

jaschag wrote:

I can see these as being very useful as logical definitions of the subset of the domain model that a particular piece of code requires to operate on. Especially so if they can act as DTO's and intrinsically define a prefetch path. Frans, how do you see these being created? Built "Manually" from the constituent entities in code or automatically via their own fetch methods? Or both? I.e. do you see them as being "first class" citizens of the entity world or merely typed entity containers? I suspect there may be much value to be added here...

Internally we had a debate about this: should we add a different type of element, like 'Business Component' which are elements build from entities, or should be introduce the ability to create an entity just like any other entity but it's not mapped onto a table but build from other entities in the system.

It's not settled yet, I lean towards the latter, but Ive to check how it works in practise.

they're units so if you fetch them, you'll be able to specify what to fetch. This is a tough problem to solve, performance wise, as fetching these entities in a hierarchy requires sub-prefetch paths (per hierarchy node) as well, so it might be that the feature looks nice on paper but in practise not a lot of people will use them in depth.

The core purpose of these entities is that you can treat a group of entity types as a single unit, like 'sales order' which has a reference to 'customer', order, order items and for example the employee who logged the order. I don't see them play a large part in extensive fetch scenario's, like lists of data, as it's more efficient to use dyn. lists or typed lists for that. However for managing data they can be helpful, also because you can add validation for a single unit so validation and BL rules are simpler.

Yes I can see the dilemma - so many potential uses. The concept of an entity hierarchy with entities composed of sub entites composed of sub sub entities and so on sounds very powerful but a potential nightmare for you! Perhaps if you factor out the services provided by an entity into those that apply to an entity container and those that apply to a raw entitry then such a mechanism may be possible.

I would still vote for one of their roles to be a strongly typed definition of a DTO in distributed scenarios. But that could be because that is what I am looking at currently

Otis wrote:

V2.1 of LLBLGen Pro will have entities constructed from entities, thus aggregated entities, so you can have 'salesorder' which contains customer, order, orderlines etc. and define rules based on the 'salesorder' entity and threat it like a single entity.

Otis wrote:

That's the plan yes. And delay loaded fields

WOW! That sounds really nice... What are delay loaded field?

Say you have a graph of Customer - Order - OrderDetails and in the Order entity you have a blob/image field with the pdf file of the physical order scanned in.

You load the data of this graph, but as you don't need the pdfs of the order entities, you should be able to avoid loading these fields as they're big and eat a lot of memory and bandwidth. Delay loaded fields will offer this.

Now, lets say you at some point want to load these pdfs into the existing entities. Delay loaded fields will also offer this.

Otis wrote:

The core purpose of these entities is that you can treat a group of entity types as a single unit, like 'sales order' which has a reference to 'customer', order, order items and for example the employee who logged the order. I don't see them play a large part in extensive fetch scenario's, like lists of data, as it's more efficient to use dyn. lists or typed lists for that. However for managing data they can be helpful, also because you can add validation for a single unit so validation and BL rules are simpler.

Hi Frans,

this is **exactly **what I am looking for and what I am missing in LLBLGen at the moment. It's very similar to what CSLA.NET proposes. Unfortunately It seems like you didn't implement the idea yet (as of LLBLGen 2.5).

Are there any plans to implement it in the next release? If not do you have any thoughts on how I could simulate it for now?

Thanks, Patrick