I'm not exactly reading a book a week, but it is close. This morning, I finished the Pro-LINQ C#2008 book by Joseph Rattz. A lot of it is a reference manaul which I will be frequently breaking open while coding LINQ, but I definitely feel more comfortable in using LINQ now than I was a couple of weeks ago. I haven't gotten to the point of ThinqLinq (I just coined that term, I should copyright it.) *Note: I just found a website that already uses the term ThinqLinq. Guess I won't be getting rich on that one.
I'll define ThinqLinq as being able to code database queries directly in LINQ without first thinking in SQL. I think it actually works to my advantage that I am relatively new to SQL Server, with most of my database experience being in Informix and Oracle, so the transition to SQL Server is being done at the same time as I am learning LINQ.
One of the dangers of learning a new language (and that's what LINQ is to me), is that you can become proficient at the language, but it may take a while to learn how to architect an application properly using it. LINQ removes months of development effort for the data access layer, and that speed may encourage bad design. Not because you want to make a bad design, but because you aren't in the code long enough during the development cycle to know it is bad design.
To me, bad design has two definable results:
1. Poor performance. In some cases this is obvious right away,in some cases it isn't until much further down the road when you see your database load go up unexpectedly as your app reaches critical mass
2. High code maintenance costs. The idea behind a good design should be that future changes should take much less time than the original effort. But if your original effort on an application was less than a day, is there really a long term payback of spending three weeks doing a huge design effort to extract ten lines of code into another class? Purists will say yes, always. Realists, working with real deadlines and real customers will say it depends.
I think what it comes to is that only experience with a new language will tell you what is and what isn't a good design. Start simple. Don't try to out guess the code or the user. Prioritize optimization based on the critical nature of the code and the size of the project. As you learn a better technique, keep a list of places where you may want to refactor existing code using that technique, and check your list frequently to see if any of those tips apply to what you are doing.
Here are my current best practices for LINQ
1. Don't try to write a best practice until you tried something at least twice
2. Never alter the autogenerated code created by SQL-Metal. Use the partial classes instead
3. Always implement your data relationships on your database. If it doesn't have any, you will save time by going inand adding them as you need them in your LINQ applications. Undoubtedly you will need them later, and the foreign key relation ships defined on the database make it easier for new developers to navigate through a large database.
4. Don't try to do everything in one query. If you need to break things out into more than one query for readability or speed, do it. Even if it seems that multiple queries will result in a lot of extra database traffic, give it a try. You may be suprised at how much better the split queries acually perform, especially if you can cache the results of one of the queries.
5. NUnit is your friend. Write lots of test cases. Write them before you write your LINQ code. You'll need every case you can get your hands on.
My next LINQ goal is to understand how it fits in with tools like SubSonic and the Entity Framework, but for now, I'm just going to focus on mastering LINQ, and learning to ThinqLinq
The next book on my reading list is Programming SQL Server 2005. I need to brush up on the SQL Server basics, and fill in some of my knowledge gaps. I don't think there will be anything earth shattering in it, just a lot of 'Oh, that's cool' things that I could never have done in Informix.
Posts
