CSLA and ADO Entity Framework

CSLA and ADO Entity Framework

Old forum URL: forums.lhotka.net/forums/t/9737.aspx

loch006 posted on Wednesday, November 10, 2010

i was considering using ADO EF as the data layer for a new project i am working on and have found it to be extremely tedious and far less functional than simply using linq to sql...

first problem is that output parameters from stored procedures have to be mapped as a result binding on the datatable object itself and can't be an actual OUTPUT param

secondly i have to map every single property of the data object to a parameter of the stored procedure after setting a stored procedure as one of the CRUD operations for a specific data object

and then in the dataportal methods, eg: the dataportal_insert method, i have to instantiate a new dataobject, fill every one of its parameters with the business object property values, and then call the .AddToWhatever table method on the dataobject

if i try to add a stored procedure as a function import it can be executed by itself but still cannot use output parameters which would be ideal for the lastchanged values

it seems liket his process takes way too much time for no extra added value and seems to tightly couple everything together to the point where each datatable object has stored procedures set for it that must be executed only under a certain context

is there any reason to not just use linq to sql?

im just wondering what other people think about CSLA and ADO EF



RockfordLhotka replied on Wednesday, November 10, 2010


is there any reason to not just use linq to sql?

The primary reason is that Microsoft isn't continuing to invest in L2S. They'll keep it running through the terms of their support agreements, but it isn't their area of focus. If you accept the obvious risks that come with what I just said, then there's no reason to stop using L2S :)

I agree with you that EF is often tedious. Fwiw, I frequently still use standard ADO.NET.

Copyright (c) Marimer LLC