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
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