Missing LINQ?
-
SQL is a dinosaur. For young developers such as myself, the extra overhead of learning a COMPLETELY different syntax construction can be considered nothing but a pain. And I mean these two things are from different worlds. I'm personally very much in favor LINQ just on the basis of making it a more C#-like syntax, let alone all of the other benefits that come along with it, such as strong typing and intellisense. Logan
That's another good point I hadn't thought of. I actually started out with database work back with SQL Server 6.5, and moved to ASP as a way to front that data. I hadn't really considered what it would be like learning SQL after starting with .Net. However, the dinosuars were around for more and 100 million years. I doubt seriously that SQL will last that long, but it won't be going away soon. If you have the luxury (or curse depending on your perspective) of working in an organization large enough to have the DBAs working independant of development, that may be enough for you. Otherwise, you may have to get used to some SQL anyway. But a good point nontheless.
Try code model generation tools at BoneSoft.com.
-
That's another good point I hadn't thought of. I actually started out with database work back with SQL Server 6.5, and moved to ASP as a way to front that data. I hadn't really considered what it would be like learning SQL after starting with .Net. However, the dinosuars were around for more and 100 million years. I doubt seriously that SQL will last that long, but it won't be going away soon. If you have the luxury (or curse depending on your perspective) of working in an organization large enough to have the DBAs working independant of development, that may be enough for you. Otherwise, you may have to get used to some SQL anyway. But a good point nontheless.
Try code model generation tools at BoneSoft.com.
Well currently my organization consists of myself ;P and yes, I've been forced to deal quite a bit with SQL, despite really focusing on the application side of things. That said, I'm glad to have learned as much as I have about database management and organization through my experience, but time and time again I'll come back to some database code I've written and I'll have forgotten exactly how to do something in SQL (usually little things like do I need a bracket here or a quote there, or how do I get that as XML again) so I'll have to look it up. If the syntax were more familiar perhaps I wouldn't have to go through that each time, and maybe I'd even remember it! ;) Logan
-
Well currently my organization consists of myself ;P and yes, I've been forced to deal quite a bit with SQL, despite really focusing on the application side of things. That said, I'm glad to have learned as much as I have about database management and organization through my experience, but time and time again I'll come back to some database code I've written and I'll have forgotten exactly how to do something in SQL (usually little things like do I need a bracket here or a quote there, or how do I get that as XML again) so I'll have to look it up. If the syntax were more familiar perhaps I wouldn't have to go through that each time, and maybe I'd even remember it! ;) Logan
Yeah I feel your pain. Anything beyond the normal day to day syntax I still regularly have to look up, which seems to waste time. Good example was just this morning I couldn't remember how to make a password case sensative and had to look it up.
SELECT *
FROM
[User] u
WHERE
u.UserName = @Uid
and (Password = @Pwd COLLATE Latin1_General_CS_AS)In case you ever need it. ;) But yeah, I suppose it's good that they are at least trying to bridge the gap and lessen the programmer's exposure to unmanaged resources. Since it's not really possible (at least quickly) to get the entire industry to support a standard in data storage, (beyond a SQL standard that's loosely supported), I guess you're left having to try to standardize within your framework/language environment. And it sounds like LINQ is a step in that direction.
Try code model generation tools at BoneSoft.com.
-
I've rarely needed to cherry pick details from XML, and in that scenario LINQ sounds like a great alternative. Because otherwise you'd have no real alternative but to use the DOM. Serialization would be gross overkill for that, I'll concede. A couple of years ago I was working for a company that ran a travel web site. They pulled all their information from several different sources, all XML, and virtually none were proper web services. I wound up writing my own tools to create XML serializable models from XML & XSD because I hated what XSD.exe produced. Once the tool was done, I could take their HUGE XML structures and create programmable entity classes in seconds. Effectively shaving months of work off in seconds. I dunno, maybe LINQ would be a more appealing solution for some. Currently other than XSD.exe, which sucks, I'm not aware of too many tools out there that generate serializable code from XML/XSD structures. XSL might be an interesting idea for transforming different models to a standard model, but XSL is a really gross language to deal with. I bet that took a lot of time and work.
Try code model generation tools at BoneSoft.com.
Interesting ideas. Thanks for your response. In fact, I am working on the travel industry and that's exactly my scenario. I never had the idea of creating programmable entity classes due to the amount of code needed for otherwise small tasks, but it sounds like a good idea, if we can make them automatically from XML/XSD. A tool such as yours would be great asset. It's a shame I am still using plain VB6 for some older products. JP
-
Interesting ideas. Thanks for your response. In fact, I am working on the travel industry and that's exactly my scenario. I never had the idea of creating programmable entity classes due to the amount of code needed for otherwise small tasks, but it sounds like a good idea, if we can make them automatically from XML/XSD. A tool such as yours would be great asset. It's a shame I am still using plain VB6 for some older products. JP
Yeouch! I don't know if I could still find my way around VB6. Yeah, we pulled from the big boys like Amadeus and Saber, and lots of smaller sources. I spent most of my time working on the car interface, so we pulled from Hertz, Enterprise, and 4 or 5 other companies, all with different XML. We had to pull all that and turn it all into our own format so they could all be presented together. It's funny how many of those companies are OTA compliant and still have VASTLY different XML models. The OTA schema is a mess. I finally completely gave up on OTA and just built seperate models for everybody. Since I could generate code for that, it saved a huge amount of time. But I still had to translate their model to ours so they could all be presented with ours. I guess if you could use LINQ in that scenario, it might be better than serialization. Maybe it's a good thing that at the time I didn't have to decide between the two. I can't imagine trying to do any of that with VB6. Good luck to you, I don't envy your situation.
Try code model generation tools at BoneSoft.com.
-
I think that MS did an awesome job on the .net languages and the framework. I am yet to see another language compare to C# and a framework compare to .NET I have used the open source cousin (mono) and wasnt to impressed, and I have used Java and still not impressed. Where MS do kinda drop the balls is with the IDE and that is where most of you get confused, you tightly associate the IDE with the framework at that time. Yes they have been released at the same time (except for v3.0 of the framework). Managed programming has for years now made it very easy for newbies to create disgusting code (Java is included here) so I really think it is an education thing. Programmers need to still under go the same trainning (whether that is personal or formal) that one use to back in the day before managed code. So they can learn about the repocutions of bad code. Have them understand memory and processing and io, and sorting algorithms etc. So that they dont just associate the idea of writing a file with system.io etc. but actually understand what the underlaying is doing. On linq I have been playing with this for a long time now. I think it is awesome, it is as said really just a mask of what is going on in the background. However from a coding efficiency it is great. Not sure how many of you have played with Rail systems like Ruby, or MVC frameworks like codeigniter etc. If you have you will appreciate Linq being here. All I have a gripe with is the IDE and would like to see something more solid in the future, I have been working with BETA 2 of Orcas for a while now as well and there still some bugs but I am hoping that gets sorted by the end of the year. ;)
Mitchell Geere
Mitchell D. Geere wrote:
Yes they have been released at the same time (except for v3.0 of the framework).
Please remember that .NET 3.0 was a marketing descision and nothing to do with it actually being version 3.0 of the Framework. At best it was 2.1 or 2.5. What was WinFX (now .NET 3.0) is just an add on. There are no changes to the .NET 2.0 framework.
Upcoming FREE developer events: * Glasgow: db4o: An Embeddable Database Engine for Object-Oriented Environments, Mock Objects, SQL Server CLR Integration, Reporting Services ... My website
-
Mitchell D. Geere wrote:
Yes they have been released at the same time (except for v3.0 of the framework).
Please remember that .NET 3.0 was a marketing descision and nothing to do with it actually being version 3.0 of the Framework. At best it was 2.1 or 2.5. What was WinFX (now .NET 3.0) is just an add on. There are no changes to the .NET 2.0 framework.
Upcoming FREE developer events: * Glasgow: db4o: An Embeddable Database Engine for Object-Oriented Environments, Mock Objects, SQL Server CLR Integration, Reporting Services ... My website
Sorry yes a mistake in my writing. 3.0 isn't a whole framework it is just merely an add on to 2.0. However my point here wasn't that, my point was that there seems to be a tight association between the frameworks and the IDE where people refer to them interchangeably. Which is wrong there is no 2003 framework there is a 1.1, but there is a 2003 IDE. Get where I am going? So alot of folk complain about the '2003 framework', but what they really mean is that their IDE is bust. :)
Mitchell Geere
-
I pretty much agree with all the points made above. I have been playing around with LINQ for quite a while now and can see big benefits from having a set of features that allow you to query several different data types/structures using one common syntax. Yes it takes a little getting used to but don't all new languages/code implementations. Surely good practice as a coder dictates that you should understand the technologies and workings of the code you are implementing? On this basis I definatly agree that the methods/classes underlying this new feature set should be taught and explained as to grasp more fully the under the hood workings and to not be led blindly down an alley. I do have major revisions with LINQ however so far from my playing. The technology seems to be totally inadequate for a multi tier environment. Take a simple n tier environemnt, database, data layer, business layer, ui layer. For the data layer you create LINQ classes to query your data structures. Take this simple senario, your UI has a button that calls a method contained in your business layer, for example User.Login(). When this method is called you want your business layer to make a call to your data layer using LINQ. When you write the code in your business layer you use the new annonymous type keyword, var, to create a smaller subset of your customer object. for example:
var _Cust = from c in DataLayer.Customers where c.UserName = "Some Name" and c.Password = "Password" select new {c.UserId, c.FirstName, c.Surname}So, in the senario above we have used projection to create a new annonymous type, which is a great complier trick on MS part. This saves us creating many different methods to return different data collections/structures for the same object etc. We can create them on the fly and loop through them etc. However here comes the point were it all comes unstuck as far as i can tell. We now want to return our new type to the UI layer so that we can use the data it contains to bind to our presentation layer. Pretty normal senario you would say, but guess what, you cannot return a annonymous data types from a method!!!! So a method trying to return a var data type will not compile. This to me seems totally crazy, microsoft give us this great power of type projection with some really neat compiler trickery but then prevent us from returning it from any of our methods which to me makes it un-usable in any n-tier system. Yes use it in a single layer in a void method but thats about all folks. How doKevinio wrote:
Surely good practice as a coder dictates that you should understand the technologies and workings of the code you are implementing?
Coder? No. Developer? Yes. To me a coder and developer are distinctly different. A coder doesn't design and doesn't architect. A coder is someone who arrived in their position by accident or chance. Someone who doesn't really care about the technology or how it works, even if they profess that they do. A Developer cares about good design and good architecture. They are genuinely interested in the technology and how it actually fits together.
Kevinio wrote:
The technology seems to be totally inadequate for a multi tier environment. Take a simple n tier environemnt, database, data layer, business layer, ui layer. For the data layer you create LINQ classes to query your data structures.
I don't think so. I don't think it belongs in the data layer. I've always said: Let the database do what it is best at. Let the database filter and sort your data. LINQ should be used, in my opinion, in the business layer on existing business objects.
Kevinio wrote:
for example User.Login().
I know what you are getting at. Although I don't think this is a valid example. The database should not be returning passwords. This query should be done exclusively in the datbase. What it is useful for is if you have already built some business objects and you want to quickly get just those with particular properties. It isn't for filtering data that should have already been filtered before reaching your application. It certainly wouldn't be any use for checking someone signing in to a system such as code project with 4million+ users.
Kevinio wrote:
So, in the senario above we have used projection to create a new annonymous type, which is a great complier trick on MS part. This saves us creating many different methods to return different data collections/structures for the same object etc.
You don't need to use anonymous types either. In the above example you could just
select c. You would only create anonymous types if it gave you an advantage for some reason. I don't see a reason in this example.Kevinio wrote:
Pretty normal senario you would say, but guess what, you cann
-
LINQ is more syntactic sugar, but it can be powerful. My only fear is how badly it will perform in the hands of the ignorant. But that's a good thing, having features that are powerful in the right hands, instead of worrying about what they can do in the wrong hands, is a step towards the C++ approach to language design. I applaud that. Now they just need to make switch statements more useful, and provide a meaningful const keyword.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
My only fear is how badly it will perform in the hands of the ignorant. But that's a good thing, having features that are powerful in the right hands, instead of worrying about what they can do in the wrong hands
Kind of like Nuclear Weapons, eh? :):laugh:
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
-
I appreciate the recommendation. But his couple of points were made by nicer people. :-D
Try code model generation tools at BoneSoft.com.
-
Kevinio wrote:
Surely good practice as a coder dictates that you should understand the technologies and workings of the code you are implementing?
Coder? No. Developer? Yes. To me a coder and developer are distinctly different. A coder doesn't design and doesn't architect. A coder is someone who arrived in their position by accident or chance. Someone who doesn't really care about the technology or how it works, even if they profess that they do. A Developer cares about good design and good architecture. They are genuinely interested in the technology and how it actually fits together.
Kevinio wrote:
The technology seems to be totally inadequate for a multi tier environment. Take a simple n tier environemnt, database, data layer, business layer, ui layer. For the data layer you create LINQ classes to query your data structures.
I don't think so. I don't think it belongs in the data layer. I've always said: Let the database do what it is best at. Let the database filter and sort your data. LINQ should be used, in my opinion, in the business layer on existing business objects.
Kevinio wrote:
for example User.Login().
I know what you are getting at. Although I don't think this is a valid example. The database should not be returning passwords. This query should be done exclusively in the datbase. What it is useful for is if you have already built some business objects and you want to quickly get just those with particular properties. It isn't for filtering data that should have already been filtered before reaching your application. It certainly wouldn't be any use for checking someone signing in to a system such as code project with 4million+ users.
Kevinio wrote:
So, in the senario above we have used projection to create a new annonymous type, which is a great complier trick on MS part. This saves us creating many different methods to return different data collections/structures for the same object etc.
You don't need to use anonymous types either. In the above example you could just
select c. You would only create anonymous types if it gave you an advantage for some reason. I don't see a reason in this example.Kevinio wrote:
Pretty normal senario you would say, but guess what, you cann
Colin many thanks for your feeback, just thought i would clarify a few points on your feeback
Colin Angus Mackay wrote:
Coder? No. Developer? Yes. To me a coder and developer are distinctly different. A coder doesn't design and doesn't architect. A coder is someone who arrived in their position by accident or chance. Someone who doesn't really care about the technology or how it works, even if they profess that they do. A Developer cares about good design and good architecture. They are genuinely interested in the technology and how it actually fits together.
Im not quite sure why you are being quite so pedantic here, i use the term coder to refer to people who write code of any nature and any language, to me a coder and a developer are the same thing. What is important and the point i was making here are the practices needed to write good code.
Colin Angus Mackay wrote:
I don't think so. I don't think it belongs in the data layer. I've always said: Let the database do what it is best at. Let the database filter and sort your data. LINQ should be used, in my opinion, in the business layer on existing business objects.
You are totally correct here and i do agree with you, i was probably not clear enough in what i was saying. When i said "you create LINQ classes to query your data structures" I was refering to the use of the new LinqToSql(dbml) files, that, by selecting your db tables build your data access class for you. In not saying that this is the correct way of doing it but it is a feature pushed by MS so i thought i would use it to try and highlight some of the issues i am talking about. The database would still be doing the sorting and filtering, just the SQL code that is run would be generated through the LINQ code that you write. Sorry if i was not clear on this.
Colin Angus Mackay wrote:
I know what you are getting at. Although I don't think this is a valid example. The database should not be returning passwords. This query should be done exclusively in the datbase. What it is useful for is if you have already built some business objects and you want to quickly get just those with particular properties. It isn't for filtering data that should have already been filtered before reaching your application. It certainly wouldn't be any use for checking someone signing in to a system such as code project with 4million+ users
-
Alright already! Enough flame-throwing. My bad. Let's all hold hands and sing Koombaya instead :-D
-
Colin many thanks for your feeback, just thought i would clarify a few points on your feeback
Colin Angus Mackay wrote:
Coder? No. Developer? Yes. To me a coder and developer are distinctly different. A coder doesn't design and doesn't architect. A coder is someone who arrived in their position by accident or chance. Someone who doesn't really care about the technology or how it works, even if they profess that they do. A Developer cares about good design and good architecture. They are genuinely interested in the technology and how it actually fits together.
Im not quite sure why you are being quite so pedantic here, i use the term coder to refer to people who write code of any nature and any language, to me a coder and a developer are the same thing. What is important and the point i was making here are the practices needed to write good code.
Colin Angus Mackay wrote:
I don't think so. I don't think it belongs in the data layer. I've always said: Let the database do what it is best at. Let the database filter and sort your data. LINQ should be used, in my opinion, in the business layer on existing business objects.
You are totally correct here and i do agree with you, i was probably not clear enough in what i was saying. When i said "you create LINQ classes to query your data structures" I was refering to the use of the new LinqToSql(dbml) files, that, by selecting your db tables build your data access class for you. In not saying that this is the correct way of doing it but it is a feature pushed by MS so i thought i would use it to try and highlight some of the issues i am talking about. The database would still be doing the sorting and filtering, just the SQL code that is run would be generated through the LINQ code that you write. Sorry if i was not clear on this.
Colin Angus Mackay wrote:
I know what you are getting at. Although I don't think this is a valid example. The database should not be returning passwords. This query should be done exclusively in the datbase. What it is useful for is if you have already built some business objects and you want to quickly get just those with particular properties. It isn't for filtering data that should have already been filtered before reaching your application. It certainly wouldn't be any use for checking someone signing in to a system such as code project with 4million+ users
Kevinio wrote:
I am still very exited about LINQ and the prospects that it brings but at the same time i am pretty disapointed about the lack of ability to return annoymous types from any methods (including the same tier as you mention). Hopefully MS can work some more of that compiler magic and make it a possibility in the future
They are working on dynamic languages that work with .NET to perhaps this is a stepping stone to them, that these new features will be more useful in a more dynamic environment. Personally, having worked with both dynamic and static languages I prefer the latter. I find it is too easy to shoot yourself in the foot with a dynamic language because you don't realise you've got a loaded gun. With a static language at least you are more aware of what you have before deciding to do something with it.
Upcoming FREE developer events: * Glasgow: db4o: An Embeddable Database Engine for Object-Oriented Environments, Mock Objects, SQL Server CLR Integration, Reporting Services ... My website
-
Kevinio wrote:
I am still very exited about LINQ and the prospects that it brings but at the same time i am pretty disapointed about the lack of ability to return annoymous types from any methods (including the same tier as you mention). Hopefully MS can work some more of that compiler magic and make it a possibility in the future
They are working on dynamic languages that work with .NET to perhaps this is a stepping stone to them, that these new features will be more useful in a more dynamic environment. Personally, having worked with both dynamic and static languages I prefer the latter. I find it is too easy to shoot yourself in the foot with a dynamic language because you don't realise you've got a loaded gun. With a static language at least you are more aware of what you have before deciding to do something with it.
Upcoming FREE developer events: * Glasgow: db4o: An Embeddable Database Engine for Object-Oriented Environments, Mock Objects, SQL Server CLR Integration, Reporting Services ... My website
Colin Angus Mackay wrote:
Personally, having worked with both dynamic and static languages I prefer the latter. I find it is too easy to shoot yourself in the foot with a dynamic language because you don't realise you've got a loaded gun. With a static language at least you are more aware of what you have before deciding to do something with it.
Very good point and very well put. I to favour the use of static languages but an good balance between the two where neccessary gives the developer :) a great amount of freedom in what they are able to do. Definatly dynamic languages require a much more careful arroache to their implementaion