Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Architecture> If to DTO, use POCO or DataSets ?
 

Pages: 1
Architecture
If to DTO, use POCO or DataSets ?
Page:1/1 

  Print all messages in this thread  
Poster Message
omar
User



Location:
Salmiya, Kuwait
Joined on:
15-Oct-2004 15:44:57
Posted:
569 posts
# Posted on: 16-Oct-2009 08:14:40.  
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
We don't know who we are until we see what we can do  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8098 posts
# Posted on: 18-Oct-2009 22:13:47.  
Here is a discussion about POCO and LLBLGen: http://llblgen.com/tinyforum/Messages.aspx?ThreadID=9229

David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
omar
User



Location:
Salmiya, Kuwait
Joined on:
15-Oct-2004 15:44:57
Posted:
569 posts
# Posted on: 19-Oct-2009 13:22:40.  
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:

Quote:
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
We don't know who we are until we see what we can do  Top
omar
User



Location:
Salmiya, Kuwait
Joined on:
15-Oct-2004 15:44:57
Posted:
569 posts
# Posted on: 20-Oct-2009 11:09:58.  
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 nowEmbarrassed) as honestly I am happy with LLBL's framework as it is now


We don't know who we are until we see what we can do  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37797 posts
# Posted on: 03-Nov-2009 16:00:40.  
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 Regular Smiley. 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 Wink)
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.