>>>>I've just changed it to IQueryable in the base classes. Now I'll have to fix all application errors due to this change.
>>>
>>>OK, I know I've asked this before. Why go through all the trouble on this, when you could just use stored procs or even straight sql pass through? This is low-hanging fruit functionality, IMO being made overly complicated. Not trying to be a pain - would truly like to understand why a development team would take this approach.
>>
>>Hmm. In this case all of Naomi's problems stem from the use of the added GetAll() method. I've found that DBs (and the EF model) can get awfully cluttered with SPs that may be only needed by one developer in one specific part of the app.
>
>I agree that some implementations exploded out far too many procs and the entire approach requires major refactoring. You're absolutely right.
>
>My point is that it's almost 2017 and ORM tools, LINQ, EF, etc. are all at least 10 years old. Going around the proverbial mulberry bush to handle mundane tasks is an indicator that these tools just haven't matured as well as they should - or maybe some of the approaches were just flawed to begin with.

Hmm. Seems to me that working in .NET with a relational database as the back end is an inherent mismatch - ORM is essential and, for 'mundane' tasks EF works pretty well. You're right that in more complex situations it can still be a pain (especially if the underlying DB structure is still in a state of flux) OTOH working with DataSets (even typed) is, and always was, clunky - bulky, unwieldy objects to pass around....

>I'll take heat for this - but I have yet to see compelling arguments for LINQ to SQL-type products and certain uses of Entity Frameworks. When I see people start sentences with, "If I had written the SQL myself, I would have used feature XYZ to make things more robust/easier/etc", my reaction is....well, you've known me long enough to know what my reaction....but if not, I'll give you a hint...it starts with, "then write the bloody SQL yourself" :)

Admittedly Linq may not always produce optimal T-SQL - but usually it's 'good enough' and can be tweaked. Given my limited knowledge of T-SQL it probably does a better job than I would anyway :-}

As always, this all depends on the type of application we're working on - I perfectly happy to respect you opinion.