The question I am raising here is not wither to use DTO or not as I believe LLBL provides a framework to accommodate both using DTO or Entities (and using DTO in my opinion should be considered per the database design and the project at hand)

The question I am asking here if we want to use DTO objects to transfer data between the application’s tiers (primarily between BL and UI) then should we use POCO objects or DataSets?

Using POCO PROS: Simple

CONS: high maintenance especially for projects with hundreds of entities

Using DataSets PROS: excellent toolset support in VS that easies the creation and to some degree minimizes the maintenance overhead compared to POCO (though does not diminish it)

CONS: as a friend said, DataSets main disadvantage is that .. its NOT POCO !!

Embracing pragmatism that FRANS always preached I would like very much to probe LLBL community to their thinking and use of DTO in LLBL projects

Here is a discussion about POCO and LLBLGen: http://llblgen.com/tinyforum/Messages.aspx?ThreadID=9229

Thank you daelmo for the link. Reading it reminded me how educational it can be just to be around the LLBL forum

For the sake of others that could come across this thread, here is my take on the referenced thread after reading it:

1- POCO is NOT what I thought. I thought POCO are just simple CLR objects that do not inherit any base class BUT as Frans explained in the thread:

That's the misunderstanding about POCO: you never deal with an object instantiation of your own class, you always work at runtime with an object instantiation of a different class, be it a proxy or a post-compilation created class which is your original class + all the framework goo to make it possible to use the framework class

2- The main reason most people are raising the POCO issue is the claim of vendor lock-in. Basically, people are afraid of using entities everywhere. This is something I am neither worried of nor agree on the concern of Entities-Everywhere as have been proven by MS own Entity-Framework where MS is pitching their EF as the new RecordSets/DataSets replacement (to put it simply)

3- My case was for using a DTO to simplify the communication of loaded entities between BL and UI. My entities when loaded from the DB can have so many de-normalized data that I dont want the UI to change. Instead of using some fail-safe code against the UI tampering with these entity fields, I choose to exchange all "Data" between the UI and BL using simple objects (will not call them POCO anymore as per Frans's definition). The UI and BL can still use entities to do their own thing BUT only when they are talking to each other they exchange simple-objects

4- I find DataSets better suited for UI<==>BL communication than simple-objects because both can serve to communicate the data in a strongly-typed fashion but DataSets have great tooling support from VS

It seems MS are adding POCO support to their EF

http://blogs.msdn.com/adonet/archive/2009/05/20/entity-framework-4-0-beta-1-bits-now-available-in-the-vs-2010-and-net-4-beta-1.aspx

This is coming in the VS2010 under the umbrella of EF4.0/.NET 4.0

Here is another link explaining initial encounters

http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

The thing is I take out of all this is that LLBL needs to add support for POCO if nothing else from a marketing and product offering perspective. LLBL is pitched for .NET the community as the best/mature/feature-complete ORM in the .NET space.

With FRANS adding support for EF (and maybe others) in the upcoming LLBL3.0, it would put a big dent in the LLBL offering not to have POCO support.

Thats just my opnion ofcourse (flashing around some of the MBA stuff I am studying now ) as honestly I am happy with LLBL's framework as it is now

POCO can't be added to llblgen pro, because the underlying framework is build around entity field objects. POCO's therefore don't make any sense.

POCO is also overrated IMHO, but that's another story.

It might be people are with v3.0 choosing a different framework while still using our designer. That's ok, as that's the whole point of the multi-framework to begin with . One will find out tho that our runtime is pretty feature rich and therefore a choice is always with consequences (but one can switch back )