September 22, 2008 at 11:17 am
Adam Machanic (9/22/2008)
Exactly; doing that work would defeat the whole purpose of LINQ. And it still wouldn't be compile-time verifiable.
I'm just curious, how would you expect any object relational mapper to handle the case of varying results from a procedure? What kind of result type would you expect to get from a method call that could return 2 different table structures? Maybe the best you could do is say the method returns an object and have the calling code test the result to see exactly what kind of type it is. Or you could return a container class of sorts with each table structure a property of it. Something like this:
public class ProcedureResults {
public VariableResultShapesResult1 Results1;
public VariableResultShapesResult2 Results2;
}
In this case you'd more than likely be returning a well-defined set of results from the procedure instead of a varying result set.
It's actually not that hard to write the code to call the database though, the attributes on the method you create handle much of the work for you.
[Function(Name="dbo.VariableResultShapes")] is where you specify the stored procedure name
[ResultType(typeof(VariableResultShapesResult1))] specifies the first result type
[ResultType(typeof(VariableResultShapesResult2))] specifies the second and so on
To actually make the call you'd use a line similar to the following:
IExecuteResult result = this.ExecuteMethodCall(this, ((MethodInfo) (MethodInfo.GetCurrentMethod())), param);
Those helper attributes and method calls are just as much a part of LINQ to SQL as the automatic drag and drop designer, they help you to connect to the database.
September 22, 2008 at 11:29 am
Timothy (9/22/2008)
I'm just curious, how would you expect any object relational mapper to handle the case of varying results from a procedure? What kind of result type would you expect to get from a method call that could return 2 different table structures?
If you look at the example I posted, you'll notice one output defined per potential shape. That's one option -- let the client processing code handle both outputs on each request, and in the case of the one that wasn't used, it will just have no work to do. The other option is to define a combined output shape that envelops both (or all) of the possibilities, e.g. a table type with nullable columns, and have everything do it that way. Either way, the idea is to have a consistent output shape on every call, just like you would with any standard method in the majority of OO languages.
--
Adam Machanic
whoisactive
September 23, 2008 at 5:52 am
Adam Machanic (9/22/2008)
Matt Miller (9/22/2008)
Agreed. Still - my biggest objection to it is the separation of duties issue. Since we're back to putting what essentially boils down to dynamic SQL in the presentation layer ...Why would you put this in the presentation layer? For me the best practice will stay the same: Treat a LINQ to SQL-backed DAL just like any other DAL. Encapsulate it, and expose business objects, not data, to the outer layers.
Too right, but lots of developers aren't going to see things your way. I'm dealing with those issues right now. While our team has chosen nHibernate and not Entity Framework/LINQ, the problems are still the same. They're putting all the data access code into the front-end and making the database stupid, not just taking away stored procedures, but taking away database design entirely and going with an object persistance approach. Lots of other developers are going to follow this path too until it proves wildly successful or an abject failure. So far I haven't found definitive evidence for either direction, but we DBA's are going to be going through some interesting times.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 23, 2008 at 9:02 am
Grant Fritchey (9/23/2008)
While our team has chosen nHibernate and not Entity Framework ...
Just keep thanking your lucky stars that they didn't choose EF... Here's a thread someone sent me yesterday that scares me to no end:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3908536&SiteID=1
--
Adam Machanic
whoisactive
September 23, 2008 at 10:04 am
Adam Machanic (9/23/2008)
Grant Fritchey (9/23/2008)
While our team has chosen nHibernate and not Entity Framework ...Just keep thanking your lucky stars that they didn't choose EF... Here's a thread someone sent me yesterday that scares me to no end:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3908536&SiteID=1
It took me 5 minutes of running profiler on an EF console app to decide I wasn't going to touch it. I struggle to see how EF is a solution to an existing problem - probably because I don't work in heterogeneous environment. I only ever have one database I'm working with, even on large projects. Of course I'm still trying to figure out a use case for cloud databases - it will most likely take a change of view, much like when I went from spreadsheets to rdbms 8 years ago.
September 23, 2008 at 10:27 am
Adam Machanic (9/23/2008)
Grant Fritchey (9/23/2008)
While our team has chosen nHibernate and not Entity Framework ...Just keep thanking your lucky stars that they didn't choose EF... Here's a thread someone sent me yesterday that scares me to no end:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3908536&SiteID=1
Yikes! OK, yes, that look worse, but as a friend used to say "My first husband drank, gambled and beat me. This one just beats me." While some of these things are improvements... that's not saying we're in a good place yet.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 23, 2008 at 11:33 am
developmentalmadness (9/23/2008)
Adam Machanic (9/23/2008)
Grant Fritchey (9/23/2008)
While our team has chosen nHibernate and not Entity Framework ...Just keep thanking your lucky stars that they didn't choose EF... Here's a thread someone sent me yesterday that scares me to no end:
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3908536&SiteID=1
It took me 5 minutes of running profiler on an EF console app to decide I wasn't going to touch it. I struggle to see how EF is a solution to an existing problem - probably because I don't work in heterogeneous environment. I only ever have one database I'm working with, even on large projects. Of course I'm still trying to figure out a use case for cloud databases - it will most likely take a change of view, much like when I went from spreadsheets to rdbms 8 years ago.
I find it useful when you have a small data structure in memory for the application, never against a database.
Viewing 7 posts - 46 through 51 (of 51 total)
You must be logged in to reply to this topic. Login to reply