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

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

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 do

As mentioned by a poster above the main sources - if you want to pay - are Corbis, Getty, IStock and the like. One that is left out is Image Source, located at www.imagesource.com. Image quality is very good, the lowest resolution files should easily be good enough for your needs on the web.