Last post Nov 29, 2008 03:18 AM by rickoshay
Jul 21, 2008 04:54 PM|spy590|LINK
I noticed that in the Data project the LINQ objects are really only used as data transfer objects, and the POCO objects are used throughout the rest of the application. I was under the impression that LINQ objects were closer to being domain objects than
DTOs (built in validation events and what not). Aside from keeping the application database agnostic, are there any other specific reasons why you went this route? Is it even possible to decorate POCOs with mapping attributes (similar to nHibernate) either
in code or xml?
It seems that you would end up losing the productivity boost that you get with generated classes if you end up having to create your domain objects again.
The screencasts have been awesome, by the way! Thanks for all of the hardwork you put into this Rob.
Jul 25, 2008 12:48 AM|jwscuba|LINK
well, I don't want to speak for Rob, but I believe that when making this desicion he basically didn't want the database to dictace his model and business objects. this also privided for an additional layer of ebstraction allowing for different datastores
to be brought into the system. say dropping linq to sql for xml, or subsonic. When you do this you need to make sure that the items contunie to work as planned when a new data layer is switched in. Without having to go in and make adjustmens to you business
Nov 29, 2008 02:51 AM|rickoshay|LINK
I was also puzzled by the use of the transfer-object anti-pattern that plagued early ORM technologies. Modern ORMs now allow the use of POLOs (e.g., POJOs or POCOs) as does LINQ to SQL. The idea that transfer-objects isolate your application from database
changes is obviously fallacious. It looks more like an old habit, sort of like prefixing a table with "tbl" (at least they did not prefix fields with fld, all though perhaps I should not have planted the sugggestion) only to have to remap it without the prefix.
There are some other bad smelling things in most of these LINQ to SQL demos and videos. Most take the time to set an identity column (there is no downside to simply calling that "Id" on every table by the way) but I have yet to see them add the ALL IMPORTANT
timestamp and discuss optimistic locking. That's fundamental, except perhaps if you are slapping together a couple of pages for a hardly used application. That certainly seems to have been the niche for .NET before LINQ and MVC and such.
Nov 29, 2008 03:18 AM|rickoshay|LINK
Lest I forget, there's a few allusions to dependency injection (a.k.a. inversion of control) in the demos. This is another glaring .NET hole that was plugged years ago in other other frameworks. They use the term "constructor dependency injection" which
akin to saying assembly language has unit testing because you can write a procedure that calls another for the purpose of testing it. C# has custon attributes so they should easily be able to add "real" dependency injection (a real boon for using aspect-oriented
techniques as well). Hopefully merge LINQ to SQL with the Entity Framework and by that I mean flush the Entify Framework down the toilet and move the EF team forward in a more positive direction, outside the Microsoft organization and hopefully in not-technical
areas at that.