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

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" :)