Comments on: One Entity Format Does Not Fit All http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/ a yeah yeah, i push models like weight Thu, 21 Aug 2008 23:22:51 +0000 http://wordpress.org/?v=2.3.3 By: Dave http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/#comment-325 Dave Sun, 31 Dec 2006 18:54:52 +0000 http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/#comment-325 Yeah, I was one of those in the desire-for-single-objects-camp for quite a while. So I understand where they're coming from. I think what's excited me most about LINQ is the whole "LINQ for N" idea. That's to say, you've got a nice query tool for XML, Objects, DataSets, ORM... whatever format is appropriate for the layer at hand. Yeah, I was one of those in the desire-for-single-objects-camp for quite a while. So I understand where they’re coming from.

I think what’s excited me most about LINQ is the whole “LINQ for N” idea. That’s to say, you’ve got a nice query tool for XML, Objects, DataSets, ORM… whatever format is appropriate for the layer at hand.

]]> By: Matt Warren http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/#comment-324 Matt Warren Sun, 31 Dec 2006 17:32:52 +0000 http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/#comment-324 Dave, IMO you are absolutely correct. Formalized systems like you and many others envision need formal boundaries with different attributes/behaviors. Therefore you can rarely use the same definitions on different 'tiers' or even inbetween them. The 'business' objects that LINQ to SQL generates represent a view of the database. It would be best to use these objects for only this purpose. Yet, there are other points of view, and many do desire simpler systems with single definitions across tiers. Dave, IMO you are absolutely correct. Formalized systems like you and many others envision need formal boundaries with different attributes/behaviors. Therefore you can rarely use the same definitions on different ‘tiers’ or even inbetween them. The ‘business’ objects that LINQ to SQL generates represent a view of the database. It would be best to use these objects for only this purpose. Yet, there are other points of view, and many do desire simpler systems with single definitions across tiers.

]]> By: Dave http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/#comment-276 Dave Wed, 06 Dec 2006 00:06:42 +0000 http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/#comment-276 Hey Evan -- I don't think there IS an answer... Indeed, if your application is service oriented you have at least two paradigms (xml messages aka message/data contracts & either datasets or objects in the backend)... I know there are some frameworks out there like Rocky's CSLA that attempt mobile objects and validation. I've given up on "smart DTOs" until convinced otherwise. Hey Evan — I don’t think there IS an answer… Indeed, if your application is service oriented you have at least two paradigms (xml messages aka message/data contracts & either datasets or objects in the backend)… I know there are some frameworks out there like Rocky’s CSLA that attempt mobile objects and validation. I’ve given up on “smart DTOs” until convinced otherwise.

]]> By: Evan http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/#comment-275 Evan Tue, 05 Dec 2006 23:56:51 +0000 http://laribee.com/blog/2006/12/05/one-entity-format-does-not-fit-all/#comment-275 Nice catch on the new ADO post. As for your question, I'm still trying to answer that myself. Nice catch on the new ADO post. As for your question, I’m still trying to answer that myself.

]]>