Another religious question: LINQ vs stored procedures
-
I would go with Entity Framework + Stored Procedure. With EF the advantage that we can get is the OR Mapping. Now the question goes to you, If you want to take advantage of the technology to simplify or make it better then go with EF Designer or Code first approach and also if you want to do some code re-factoring and wish to use your existing store procedure, Yes you can do so. Some interesting articles http://msdn.microsoft.com/en-us/data/gg699321.aspx[^] http://www.dotnetcurry.com/ShowArticle.aspx?ID=938[^] Thanks,
Ranjan.D
Don't mean to be dense, but I'm not really following the advantages here. What benefit do I gain by moving queries out of stored procedures and into compiled code?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
-
Given that you've been in the game for a long time, I'm glad to hear I'm not the only one who sees this as more resume enhancement / religion than a functional improvement in development. By the way, just popped over to look at your profile. Do you still fool around with film stuff?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
Christopher Duncan wrote:
Do you still fool around with film stuff?
Not much since the 1990s, when I created several interactive videos for edutainment products (and wrote the software.) Lost money, but had a blast. Since then, my biggest project was editing my daughter's wedding video (I should have done a divorce video to bookend that....) I may get back into it one of these days.
-
I remember them releasing competing db platforms at the same time. LINQ to SQL, LINQ to Entities, Entity Framwork, Apparition Architect, yada, yada. That's one of the reasons I stayed away initially. I thought it was the height of stupidity. In other words, coming from MS, I didn't give it a second thought.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
Ok, so here a link to a discussion by people who did use it in production: LINQ Discussion[^] "with my experience with EF and Linq, If you are developing an application for less than 10-20 users and not expecting any huge data, go with EF and LINQ Otherwise, Never ever use LINQ and EF. I never saw many developers who care about performance during development. So don't adopt architecture that cost you more in the long run. "
-
First of all, thanks very much to everyone who kicked in with thoughts regarding MVC. I'm currently doing some upgrades / installs for VS 2012 since I've been running 2010 so that I can give MVC 4 a go. Since I'm reevaluating technologies, here's something I just don't get - but perhaps I'm missing something. A year or two ago I played with LINQ. Essentially, it's a nice little chunk of technology to move your db queries into your code. My approach has traditionally been to use stored procedures, keeping SQL stuff in the database and procedural code / logic in the application. Why on earth would I want to move my queries into C# code? As long as the params and columns returned don't change, I can make changes all day long in Sql Server and never touch web apps or services. If my db logic is in the code, I have to recompile and deploy the binaries every time I touch something. I know it's the shiny new thing to play with but other than resume enhancement, I just don't see what value it brings to the table. What am I missing?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
Following is my comparision between Entity Framework (ORM that uses LINQ) and Stored Procedures. Stored Procedure Pros: Much faster performance over EF/LINQ, Could be updated without recompiling the code based since it's in the database, better separation of logic, you could utilize your DBAs, Works even if the database structure / design is poor, Much better security. Cons: Slow development process, unnecessary / repeated coding, No flexibility - works on only one database (I mean someday your management/client wants to move to MySQL from SQL Server, you will have to rewrite everything). Need extensive knowledge of database (I mean just knowing front-end language doesn't work). Maintain two separate things. Unit Testing nightmare. Entity Framework Pros: Crazy fast development time (you could skip one or two phases), Querying is very easy, Works even if you know only Front-End language, Flexible - you can change underlying database without changing your code base, Start coding without planning everything in advanced (for SP you need to create it first before you do anything), Only one code base to maintain, Code-First migrations makes seamless database changes (Just rebuilt the solution and push it, Magic!), If you need performance boost at particular scenario you can still use stored procedure and call it as a method. Cons: Requires almost perfect database structure/design (all the primary keys, foreign keys, constraints, normalized tables etc.), performance is not as good as SP (but you can use SP in that case, or buy a better hardware, or implement caching), your DBAs are now idle, Security is not as good as SP (Mostly any developer can do anything, in case of SP you could restrict the access of the SP and Tables to certain users), every minor changes in database call requires complete recompilation of code base. Also once you know LINQ, you can use it against XML, CSV and many other data structures. I have used EF in our latest product and it works great, few places where the performance was affected due to recursive call to methods, I changed it to stored procedures and now it's fine. I really like the abstraction and flexibility ORM offers. And now I only occasionally open SQL Server Management Studio, one less window to worry about. :)
Remind Me This - Manage, Collaborate and Execute your Project in the Cloud
-
Don't mean to be dense, but I'm not really following the advantages here. What benefit do I gain by moving queries out of stored procedures and into compiled code?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
Quote:
What benefit do I gain by moving queries out of stored procedures and into compiled code?
I see two different set of peoples arguing about the Usage , Performance, Benefits of Stored Procedures , it's maintainability etc. I'm fine with either way. I don't know how you really want to go with, I say it depends on how we are deciding to go with. That's the reason I said , The Entity Framework doesn't really restricts the usage of Stored Procs , You can still make a call but what you get with EF is the result set as object. Is it good :) I think if you are planning to move out the queries out of Stored Proc, you will end up in writing tons on code, though it's compiled I don't think there would be a great benefit. Some times you might even end up with performance issues. I have seen several hundreds to thousands lines of stored procedures, If some one tells me to move them out of it to EF compiled queries , I would question why I'm doing this ? If you are working on some new products and wish to tryout EF with mix and match SP's it's good. But I don't think it's a good idea to perform code re-factoring for the existing ones. Thanks,
Ranjan.D
-
Don't mean to be dense, but I'm not really following the advantages here. What benefit do I gain by moving queries out of stored procedures and into compiled code?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
It's the principle of keeping the code in one place, as opposed to keeping it in the right place.
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
-
It's the principle of keeping the code in one place, as opposed to keeping it in the right place.
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
-
Christopher Duncan wrote:
Do you still fool around with film stuff?
Not much since the 1990s, when I created several interactive videos for edutainment products (and wrote the software.) Lost money, but had a blast. Since then, my biggest project was editing my daughter's wedding video (I should have done a divorce video to bookend that....) I may get back into it one of these days.
A daughter's wedding is a project in and of itself. I figure the insanity of a major and largely unrehearsed production put on by amateurs is that if you still want to be married by the time it's all done, you should get married. Apparently from your comment that comes with some caveats. I'm enjoying the video stuff I've been playing with, but monetizing film, or video of any sort for that matter, is about as easy as winning the lottery. I'll do more to support my own creative work as it's just another medium in which to communicate, but it would be nice if there were a way to make a buck at it in the process.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
-
Quote:
What benefit do I gain by moving queries out of stored procedures and into compiled code?
I see two different set of peoples arguing about the Usage , Performance, Benefits of Stored Procedures , it's maintainability etc. I'm fine with either way. I don't know how you really want to go with, I say it depends on how we are deciding to go with. That's the reason I said , The Entity Framework doesn't really restricts the usage of Stored Procs , You can still make a call but what you get with EF is the result set as object. Is it good :) I think if you are planning to move out the queries out of Stored Proc, you will end up in writing tons on code, though it's compiled I don't think there would be a great benefit. Some times you might even end up with performance issues. I have seen several hundreds to thousands lines of stored procedures, If some one tells me to move them out of it to EF compiled queries , I would question why I'm doing this ? If you are working on some new products and wish to tryout EF with mix and match SP's it's good. But I don't think it's a good idea to perform code re-factoring for the existing ones. Thanks,
Ranjan.D
Actually, I'm starting a couple of new projects, but I don't see trying it out unless there are distinct and tangible benefits. Looks like it would be cool for non database stuff, but for a relational db, I'm not hearing anything it does for me that I don't get out of stored procs.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
-
Following is my comparision between Entity Framework (ORM that uses LINQ) and Stored Procedures. Stored Procedure Pros: Much faster performance over EF/LINQ, Could be updated without recompiling the code based since it's in the database, better separation of logic, you could utilize your DBAs, Works even if the database structure / design is poor, Much better security. Cons: Slow development process, unnecessary / repeated coding, No flexibility - works on only one database (I mean someday your management/client wants to move to MySQL from SQL Server, you will have to rewrite everything). Need extensive knowledge of database (I mean just knowing front-end language doesn't work). Maintain two separate things. Unit Testing nightmare. Entity Framework Pros: Crazy fast development time (you could skip one or two phases), Querying is very easy, Works even if you know only Front-End language, Flexible - you can change underlying database without changing your code base, Start coding without planning everything in advanced (for SP you need to create it first before you do anything), Only one code base to maintain, Code-First migrations makes seamless database changes (Just rebuilt the solution and push it, Magic!), If you need performance boost at particular scenario you can still use stored procedure and call it as a method. Cons: Requires almost perfect database structure/design (all the primary keys, foreign keys, constraints, normalized tables etc.), performance is not as good as SP (but you can use SP in that case, or buy a better hardware, or implement caching), your DBAs are now idle, Security is not as good as SP (Mostly any developer can do anything, in case of SP you could restrict the access of the SP and Tables to certain users), every minor changes in database call requires complete recompilation of code base. Also once you know LINQ, you can use it against XML, CSV and many other data structures. I have used EF in our latest product and it works great, few places where the performance was affected due to recursive call to methods, I changed it to stored procedures and now it's fine. I really like the abstraction and flexibility ORM offers. And now I only occasionally open SQL Server Management Studio, one less window to worry about. :)
Remind Me This - Manage, Collaborate and Execute your Project in the Cloud
Thanks for the in depth thoughts, man.
Rutvik Dave wrote:
Also once you know LINQ, you can use it against XML, CSV and many other data structures.
That seems like one of the best uses for it.
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
-
First of all, thanks very much to everyone who kicked in with thoughts regarding MVC. I'm currently doing some upgrades / installs for VS 2012 since I've been running 2010 so that I can give MVC 4 a go. Since I'm reevaluating technologies, here's something I just don't get - but perhaps I'm missing something. A year or two ago I played with LINQ. Essentially, it's a nice little chunk of technology to move your db queries into your code. My approach has traditionally been to use stored procedures, keeping SQL stuff in the database and procedural code / logic in the application. Why on earth would I want to move my queries into C# code? As long as the params and columns returned don't change, I can make changes all day long in Sql Server and never touch web apps or services. If my db logic is in the code, I have to recompile and deploy the binaries every time I touch something. I know it's the shiny new thing to play with but other than resume enhancement, I just don't see what value it brings to the table. What am I missing?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
Christopher Duncan wrote:
Why on earth would I want to move my queries into C# code?
No idea. After all why would anyone want a database layer in their application when it would obviously make more sense to scatter it throughout the business layer in exactly each spot where it is used?
Christopher Duncan wrote:
What am I missing?
Being a bit sarcastic lets suppose that you are less than a DB guru when it comes to your database. And no one else is either. And something is wrong with your database. You don't even know what. So you hire a DB guru. And they fix it. If you managed a reasonable business interface with your store procs you will have no or minimal changes to your application code. Without you will be refactoring everything.
-
First of all, thanks very much to everyone who kicked in with thoughts regarding MVC. I'm currently doing some upgrades / installs for VS 2012 since I've been running 2010 so that I can give MVC 4 a go. Since I'm reevaluating technologies, here's something I just don't get - but perhaps I'm missing something. A year or two ago I played with LINQ. Essentially, it's a nice little chunk of technology to move your db queries into your code. My approach has traditionally been to use stored procedures, keeping SQL stuff in the database and procedural code / logic in the application. Why on earth would I want to move my queries into C# code? As long as the params and columns returned don't change, I can make changes all day long in Sql Server and never touch web apps or services. If my db logic is in the code, I have to recompile and deploy the binaries every time I touch something. I know it's the shiny new thing to play with but other than resume enhancement, I just don't see what value it brings to the table. What am I missing?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
I have not and never intend to use linq to the database but then new and shiny does not attract me. Linq against iEnumerable is just excellent. EF is a nightmare for new devs, sure it is easy and very quick developing the app but they have no depth in their knowledge of the database. Take a look at some of the questions in Q&A, they have no idea how a database works. I hate black box software, if it breaks (and it does) you are screwed. EF being in it's 4th or 5th version is much more stable but is still a black box.
Never underestimate the power of human stupidity RAH
-
On heavily loaded client/server applications, stored procedures can cause major bottlenecks. I was on the fringe of at least two projects where anything more than simple stored procedures were prohibited for this reason (and they had tests to prove it.)
Joe Woodbury wrote:
stored procedures can cause major bottlenecks
You are claiming that for every single bit of SQL that implementing that in the application is going to be significantly faster? And no one has actually discovered that until now? Not to mention of course that requirements, architecture and design have far more impact on systems in terms of performance. A poor data model can completely destroy a system regardless of how it is implemented.
Joe Woodbury wrote:
and they had tests to prove it
I am guessing they had "benchmarks" to "prove" it. I suspect that for most of the major technologies that I am familiar with that I can come up with a benchmark in technology X that proves it is better than technology Y. Naturally I will be able to reverse X and Y.
-
Because stored procedures take computing time and aren't always trivial. Stored procedures aren't just a few lines of code to do, say, a select or simple update trigger, they can be entire programs which may have little to do with setting/retrieving data, but in manipulating that data. So, who should manipulate the date, the client or the server? (The answer is, of course, it depends.)
Joe Woodbury wrote:
Because stored procedures take computing time and aren't always trivial
Versus for example dragging the entire database across the network, doing calculations on a single client box and then sending the entire database back? (And just to be clear that isn't hyperbole - I actually encountered a system that did that and it would only use one client machine.)
Joe Woodbury wrote:
The answer is, of course, it depends
Exactly. Which is far different than claiming that stored procs are always bottlenecks.
-
Christopher Duncan wrote:
I get the impression people were hot to move that sort of thing to LINQ only because it was new and shiny.
My impression as well since the alternative to stored procedures is just writing normal queries. A few months ago, I used a tool that refactored some code into LINQ. The end result was only slightly shorter and much more difficult to understand than the original code. Plus, the LINQ code sucked in several more assemblies. I backed out the change. (My impression is that most things in software development are about being "new and shiny", which is a major headache when you have to maintain the code for someone who constantly got suckered by this.)
Joe Woodbury wrote:
My impression is that most things in software development are about being "new and shiny"
The band wagon that you see in the distance always looks more shiny than the one that you are on. And since you are not on it and even once you get on, you will have no idea how often it breaks down or why.
-
First of all, thanks very much to everyone who kicked in with thoughts regarding MVC. I'm currently doing some upgrades / installs for VS 2012 since I've been running 2010 so that I can give MVC 4 a go. Since I'm reevaluating technologies, here's something I just don't get - but perhaps I'm missing something. A year or two ago I played with LINQ. Essentially, it's a nice little chunk of technology to move your db queries into your code. My approach has traditionally been to use stored procedures, keeping SQL stuff in the database and procedural code / logic in the application. Why on earth would I want to move my queries into C# code? As long as the params and columns returned don't change, I can make changes all day long in Sql Server and never touch web apps or services. If my db logic is in the code, I have to recompile and deploy the binaries every time I touch something. I know it's the shiny new thing to play with but other than resume enhancement, I just don't see what value it brings to the table. What am I missing?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
They're not mutually exclusive. I use neither. Old tried-and-true still rules.
Christopher Duncan wrote:
SQL stuff in the database
The database is for data; code belongs in a code base (preferably a library).
Christopher Duncan wrote:
move my queries into C# code
Because they're not there yet, but should be? And stored procedures still leave SQL in the program anyway in the form of the EXECUTE statements and parameters, etc.
Christopher Duncan wrote:
I can make changes all day long in Sql Server and never touch web apps or services
That's a baaaaad thing. Your code relies on the procedures doing a particular thing, but the procedure could be changed to do something completely different. Or a table could be changed in a way that breaks the procedure. And besides you'd still have to update the EXECUTE statements if you add or remove parameters.
Christopher Duncan wrote:
If my db logic is in the code, I have to recompile and deploy the binaries every time I touch something
Exactly; that's a gooood thing.
Christopher Duncan wrote:
I know it's the shiny new thing to play with but other than resume enhancement, I just don't see what value it brings to the table
That's about right. There's a guy on my team now who seems to think that every new thing is the bestest way to do things and any (me) who want to stick with tried-and-true need to be enlightened.
-
First of all, thanks very much to everyone who kicked in with thoughts regarding MVC. I'm currently doing some upgrades / installs for VS 2012 since I've been running 2010 so that I can give MVC 4 a go. Since I'm reevaluating technologies, here's something I just don't get - but perhaps I'm missing something. A year or two ago I played with LINQ. Essentially, it's a nice little chunk of technology to move your db queries into your code. My approach has traditionally been to use stored procedures, keeping SQL stuff in the database and procedural code / logic in the application. Why on earth would I want to move my queries into C# code? As long as the params and columns returned don't change, I can make changes all day long in Sql Server and never touch web apps or services. If my db logic is in the code, I have to recompile and deploy the binaries every time I touch something. I know it's the shiny new thing to play with but other than resume enhancement, I just don't see what value it brings to the table. What am I missing?
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World
While I would say you're not missing anything, my experience is that people who write SP's have really no good practices regarding re-use (I believe another person responded about the lack of re-use with SP's as well.) And the triggers can get huge, spaghetti code, and invariably have undocumented logic and special case handlers, often using hardcoded data values. It's a mess, and when you talk to the people managing the code, they invariably say, we know it's a mess but we've had to make all these patches without any budget to fix the real underlying problems. And why's that? Because that would require changes to application, and the app devs, that were outsourced to write the app to begin with, are no longer around and nobody knows how to make changes in THAT code base without breaking half a dozen other features. So, that describes my real-world experiences, and probably those of many other people. Also (stepping down from my rant platform), what you're describing in both cases is a 2-tier environment in most cases: app talking directly to the database. I hope I never have to work in a 2-tier environment ever again, but most people don't understand the benefits of a 3-tier environment. First off, you can isolate the application from "the database business." The stuff that manipulates data in the database's representation (aka schema) rather than the application's model, which can be quite different (but I'm not saying anything you don't already know.) But, what I like to do is then choose whether something should be an SP, or the SQL can be auto-generated by the middle tier, or it pulls in additional metadata that supplements the DB schema for further automation, or, as a last resort, the code in the middle tier does some processing of the data in C# (or whatever.) But it's hard to convince people to take the time to architect a 3-tier system in which most stuff can be handled by metadata (schema + domain-specific declarative stuff) and then leverage either the middle tier or the SP's for the stuff that doesn't fit. So, the question, in my mind, isn't "what am I missing with SP's vs Linq vs EF?", but "why am I still stuck in a 2-tier development environment?" Well, that's my somewhat ranty reply. :) Marc
-
Joe Woodbury wrote:
stored procedures can cause major bottlenecks
You are claiming that for every single bit of SQL that implementing that in the application is going to be significantly faster? And no one has actually discovered that until now? Not to mention of course that requirements, architecture and design have far more impact on systems in terms of performance. A poor data model can completely destroy a system regardless of how it is implemented.
Joe Woodbury wrote:
and they had tests to prove it
I am guessing they had "benchmarks" to "prove" it. I suspect that for most of the major technologies that I am familiar with that I can come up with a benchmark in technology X that proves it is better than technology Y. Naturally I will be able to reverse X and Y.
You do you understand the meaning of the word "can" right? You are arguing assertions I never made nor even discussed. To turn this around, are you honestly asserting that stored procedures have zero CPU cost? Moreover, have you seen what some developers put in stored procedures?
jschell wrote:
I am guessing they had "benchmarks" to "prove" it.
No, actual tests with actual databases with terabytes of data which could get under extremely heavy loads due to tens of thousands of clients. Offloading some of the processing to clients helped immensely.
-
Joe Woodbury wrote:
Because stored procedures take computing time and aren't always trivial
Versus for example dragging the entire database across the network, doing calculations on a single client box and then sending the entire database back? (And just to be clear that isn't hyperbole - I actually encountered a system that did that and it would only use one client machine.)
Joe Woodbury wrote:
The answer is, of course, it depends
Exactly. Which is far different than claiming that stored procs are always bottlenecks.
jschell wrote:
Exactly. Which is far different than claiming that stored procs are always bottlenecks.
This pisses me off. I NEVER said that stored procedures are always bottlenecks. I said they CAN be bottlenecks and they can be. (Can is a conditional. Unfortunately, this isn't the first time you've distorted what was written, creating a straw man and then attacked the writer. It's getting tiresome. Please learn to read before replying.)
-
While I would say you're not missing anything, my experience is that people who write SP's have really no good practices regarding re-use (I believe another person responded about the lack of re-use with SP's as well.) And the triggers can get huge, spaghetti code, and invariably have undocumented logic and special case handlers, often using hardcoded data values. It's a mess, and when you talk to the people managing the code, they invariably say, we know it's a mess but we've had to make all these patches without any budget to fix the real underlying problems. And why's that? Because that would require changes to application, and the app devs, that were outsourced to write the app to begin with, are no longer around and nobody knows how to make changes in THAT code base without breaking half a dozen other features. So, that describes my real-world experiences, and probably those of many other people. Also (stepping down from my rant platform), what you're describing in both cases is a 2-tier environment in most cases: app talking directly to the database. I hope I never have to work in a 2-tier environment ever again, but most people don't understand the benefits of a 3-tier environment. First off, you can isolate the application from "the database business." The stuff that manipulates data in the database's representation (aka schema) rather than the application's model, which can be quite different (but I'm not saying anything you don't already know.) But, what I like to do is then choose whether something should be an SP, or the SQL can be auto-generated by the middle tier, or it pulls in additional metadata that supplements the DB schema for further automation, or, as a last resort, the code in the middle tier does some processing of the data in C# (or whatever.) But it's hard to convince people to take the time to architect a 3-tier system in which most stuff can be handled by metadata (schema + domain-specific declarative stuff) and then leverage either the middle tier or the SP's for the stuff that doesn't fit. So, the question, in my mind, isn't "what am I missing with SP's vs Linq vs EF?", but "why am I still stuck in a 2-tier development environment?" Well, that's my somewhat ranty reply. :) Marc
I'm totally with you conceptually, although the rather loose way I phrased things allowed you to make an incorrect assumption. It doesn't matter if you have 2 tiers or 42 - ultimately, you have to talk to the database. When you do, you can write your queries in compiled code, be it a separate assembly, a web service, etc. or you can write them in stored procedures. My point is that I don't see the benefit in writing queries in a compiled, procedural language as opposed to letting sql be sql and do what you pay it to do. On the other hand, it sounds like using LING with non relational db stuff could be very handy indeed. So, put down that flamethrower, son, and keep your hands where I can see them. :-D
Christopher Duncan Author of Unite the Tribes: Leadership Skills for Technology Managers (2nd ed, just released) Have Fun, Get Paid: How to Make a Living With Your Creativity (Due Nov 2013) The Career Programmer: Guerilla Tactics for an Imperfect World