|
I looked into this and no real solution. Have you found a way to do this?
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
No, I have not found a solution.
I suspect it is buried in the container classes or iterators some place, but I haven't had time to look.
It wasn't a high-priority issue for me, so I am currently doing without.
|
|
|
|
|
kalkwarf wrote: I suspect it is buried in the container classes or iterators some place
I would think so. For fun I am going to dig around at this and let you know if I run across anything 
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
So for the last 11 years or so I've been working to push as much of the query work in the database. So you build an objet that calls a stored proc the gives you the data that you are looking for. So now linq comes out which seems to fly in the face of that. I'm watching some of the videos on msdn and she is doing a bunch of stuff that should really be done in the database.
Am I wrong? I see some uses for link. I like the DAL but I think when you get to using join's in link you have gone too far.
|
|
|
|
|
So you see what happens when you watch too many MS videos. You start all your sentances with "So".
|
|
|
|
|
lol 
|
|
|
|
|
Personally I'm with you, I've always put as much of the data querying and data processing on to the DB as possible (where appropriate of course) because the DB is designed for such thing and is very efficient at handling large data sets.
Linq works on the current trend (.Net included) of making performance trade offs in return for ease of use in the form of productivity and maintainability.
I haven't had a chance to get to grips with Linq yet and really use it in anger so it'll be interesting to find out if it's suitable to use instead of stored procs.
One thing to remember is that Linq is about more than just databases, it allows you to do this querying with XML and even objects/collections which Stored Procs arn't so good at handling 
|
|
|
|
|
So you make it sound like Linq and Stored Procedures are mutually exclusive. I have no experience with Linq beyond reading a few articles but I would find that surprising based on my initial grasp of it.
|
|
|
|
|
Well you could use Linq on a result set returned by a stored procedure, or you could use both in their appropriate places. They arn't mutually exclusive but the OP was saying that the tutorials he's seen have been demonstrating Linq with Sql Server in situations where some people have traditionally used Stored Procs.
I was agreeing that personally I use Stored Procs in those situations but I was also trying to point out the different advantages of Linq and that it's not just limited to Sql Server.
EDIT: PS congrats on your second year as an MVP
|
|
|
|
|
Linq can be used for lots of things beyond just DB stuff. Like as a replacement for XQuery in xml docs and for searching collections.
My point is that if your just searching data from a database, linq probably isn't the best way to do it.
So I think there is a place for linq, but it's not the end all be all.
|
|
|
|
|
Tad McClellan wrote: I'm watching some of the videos on msdn and she is doing a bunch of stuff that should really be done in the database.
Microsoft, I think, try to cater for everyone. So, if you have a small project then LINQ to SQL could be useful. For an enterprise application I wouldn't rely on it.
However, you can use LINQ with stored procedures, so you can continue to keep the querying stuff in the database (where it should be) and use some of the other features of linq to do smaller tasks in the .NET application.
I am very much in the camp that the application should access the database through stored procedures only.
|
|
|
|
|
I tell you where Linq is more interesting - it's the point where you use it to perform joins on collection objects. That's when the fun begins. I agree though that Linq to Sql can lead you to do too much outside of the database and you have to be really careful that you don't pass the data context away from the DAL.
|
|
|
|
|
Pete O'Hanlon wrote: and you have to be really careful that you don't pass the data context away from the DAL.
Why ?
|
|
|
|
|
N a v a n e e t h wrote: Pete O'Hanlon wrote:
and you have to be really careful that you don't pass the data context away from the DAL.
Why ?
If the context is available outside of the DAL, then you can completely bypass the DAL. In other words, you could bind directly to the data from the database. This means that you've suddenly gone from a neat n-tier architecture to one where the GUI has knowledge of the database itself (and this isn't what the GUI is supposed to do). Have a read about the principles behind n-tier architecture and separation of layers.
|
|
|
|
|
Thanks Pete.
Pete O'Hanlon wrote: Have a read about the principles behind n-tier architecture and separation of layers.
Yes I do have basic idea on them. But when it is mixed up with LINQ, I am confused.
|
|
|
|
|
N a v a n e e t h wrote: But when it is mixed up with LINQ, I am confused
You're not the only one. I'm currently working with Marc Clifton to try and define some best practices which hopefully will alleviate some of the confusion.
|
|
|
|
|
You can query your domain objects using LINQ. They can translate the query into a storage mechanism specific query.
Our current query API (in Diamond Binding) is based on the domain objects - so when you use Expressions or OQL you are querying the domain - say Employee.Manager.Name == Fred. This will be translated under the hood into an appropriate SQL query to return a List< Employee >
I think the temptation is there to bypass your DAL, which is bad, mmkay - but allowing your domain objects to be queried ad-hoc (using the _domain_ terms) is a big productivity boost, and doesnt compromise your architecture. Of course this means your DAL has to be 'smart' enough - which generally isn't the case when you are using 'dumb' codegen to spit out a whole DAL.
|
|
|
|
|
|
Oh I agree. The key here is the flexibility of your datalayer and the strength of your design.
|
|
|
|
|
Pete O'Hanlon wrote: I'm currently working with Marc Clifton to try and define some best practices which hopefully will alleviate some of the confusion.
Cool. So I am expecting another great article. Looking forward on reading it
|
|
|
|
|
I have made a small software which requires .Net framework 2.0 and Sql server Express.I want to make a setup file which automatically installs these two components.
How can i achieve this??
|
|
|
|
|
Don't cross post.
I answered your question over in the Visual Studio forum.
|
|
|
|
|
I have the 1.0, 1.1, and 2.0 frameworks installed on my PC. I'm developing in VS03. When I build and run my application is it running against the 1.1 or 2.0 framework?
Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop.
-- Matthew Faithfull
|
|
|
|
|
Visual Studio .NET 2002 -> .NET Framework 1.0
Visual Studio .NET 2003 -> .NET Framework 1.1
Visual Studio 2005 -> .NET Framework 2.0 or 3.0 (if Visual Studio extensions are installed)
Visual Studio 2008 -> .NET Framework 2.0, 3.0, or 3.5 (selectable)
|
|
|
|
|
Thanks, that's what I thought. I was asked to make sure the newer framework wasn't claim jumping somehow.
Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop.
-- Matthew Faithfull
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
