Using LINQ
-
Background:
In my 5 years of software development the most modern development tool I have used is Visual Studio 2003, writing C++ services and MFC apps. In school I used a bunch of languages,but roughly 50% of the time I used C#.
The assignment:
I was told to take the program that I have worked on for the past 3 year, but has been in development for 12 years, and modify it for a whole new purpose/program. It is made up of 12 or so major components with around 1.5 million lines of code. They want me to use some of the look and feel of the GUI, but the two programs are completely unrelated. Oh and I was given 8 weeks to implement a handful of core features for a demo to the customer. My manager's manager's manager's manager told me what I'm making is the most important thing the division is doing right now. If the customer doesn't like what they see in 8 weeks, they will cancel the contract and a bunch of us will probably be laid off. No pressure. The good part about this is if I can pull it off, it will be great for my career.
The LINQ part:
About an hour into the first meeting I made up my mind that it would take longer to modify the old program then it would to just write it from scratch using C#, VS 2010. I had heard some buzz about LINQ so I spent a few days experimenting with it and decided it would be great for this demo phase. So far I am pleased and I have finished 80% of the needed functionality in 2.5 weeks. So why am I posting this? I'm concerned about the performance and scalability of LINQ. I just don't know enough about it and I can't find any information about it's use in a large program. When the demo is over, should I scrap it and go to something else? or am I on the right track?
-
What kind of scalability are we talking about here? 500% growth a year, or 10% growth a year? Also, what's the budget like for throwing hardware at it?
-
@blakeyrat said:
What kind of scalability are we talking about here? 500% growth a year, or 10% growth a year? Also, what's the budget like for throwing hardware at it?
For scalability, I can't put a percentage on it. I assume once it is fielded it will be used around the clock by 20 - 30 users at each of 6 sites. Each site will be stand alone in the beginning but there are plans to have remote access (web interface) and DB replication. Phase 1 of the contract will last 3 years with 5 - 10 developers. I'm not sure if that answers your question.
I'm limited to a single server for the DB and whatever services I need running on it (I need to write a simple service that will fire commands when stuff happens to the "schedule." Think of this like the reminder window that pops up when a meeting is about to begin that is on your Outlook calendar, but it will instead reconfigure some hardware). It will probably be something like a quad core xeon with 8GB ram. The client app. will be on medium grade workstations running Windows XP. I hope they decide to go to Win 7 in the next few years.
-
LinQ itself won't be a performance or scalability issue but the overall architecture of the project will. If you're using a database, use set based operations and stored procedures. Make sure any calls to web services are not overly chatty. Don't use idioms that require serialisation (lock a table/some object while a user is deciding what to do). That kind of thing. The main danger I've seen with LinQ is that you think you're using a DB in it's raw, set based way (i.e. fast) and some quirk of the query or layering bypasses an index and/or injects a massive blob of XML/object construction and/or makes a billion calls where one simple query would suffice. Test, measure, test, profile, test....never assume your one line change hasn't fundementally altered what goes on under the hood.
Oh, and if you're limited to a single server for any part of it then it's not exactly as if your company depends on it. You need at least 2 servers for 24x7 otherwise it's difficult to upgrade and your DR is seriously compromised.
-
remember to use Transaction Readuncommited with Linq db access whenever you can
-
@zzzxtreme said:
remember to use Transaction Readuncommited with Linq db access whenever you can
No, only use Read Uncommitted when you don't care about dirty reads or know for sure that your application cannot create situations where you could have dirty reads
