I have spent a fair amount of time researching the various new and improved features in.Net 3.5 that I haven’t worked with before. In particular, I have been studying up on LINQ, Presentation Foundation, Communication Foundation, Workflow foundation, and Data Entity Framework.
I think I have a fair conceptual understanding these things, but no work experience with them yet. When you read about them in books they all look cool and wonderful, but that is far cry from practical work experience. My questions are: Which of the above technologies should be avoided and which pursued more seriously? Which are buggy and not ready for prime time? Which are resources hogs or yield sluggish performance? Which are finicky and hard to master or understand? I know that detailed answers are too much to ask for, but any guidance based on personal experience would be very helpful at this stage. Thanks in advance for any response to these questions. The rest of this is a fuller explanation of my situation in case it affects your advice. Read or ignore as you see fit. Later this year the company I work for will begin a major overall of its main application. Basically we are going to rebuild it from the ground up. I am the senior programmer/project manager/ scapegoat for the project. I have a fair background spanning 25+ years in developing applications from scratch. I have worked in many different environments and businesses, and have experience using many programming languages (C, C++, and various versions of VB including .Net 2.0 just to name a few). I am able to learn new technology quickly, but most of my team typically requires a lot of guidance. Several are still grappling with the difference between object orientated and structured programming. Including any of these technologies means I will have to teach them how to use it and explain (many times) precisely how it works before they fully grasp it. The current version of our application was originally written back in the early 1980’s by amateur programmers using the (very) dead language called RPG. It has survived this long because we are in a vertical market with little competition and users who fear change. I want to bring the application up to modern standards and create a sturdy foundation on which to build and expand the company for the next decade or two. I expect it will take between 1-2 years to implement the core functionality, with significant additional features added for another 1-2 years after that. The new version will be windows application with no expectation that it will ever be a web-browser style application. It will likely be a distributed application; i.e. the user portion will run on the individual workstations and make calls to one or more servers to execute business and data access logic. There may be some calls to web-services, but that will be at most a small part of the overall application. Add-ons to the main application will need remote access to the server-side objects, and some will need to work in a disconnected state. We will be working in .Net 3.5 using either C# or VB. (C# if I win that argument.) We plan to use SQL Server as our application database and Reporting Services for our reporting needs. The majority of our customers are small businesses with few users (less than 5). We expect that the Express versions of SQL Server and Reporting Services will be sufficient for their needs. A few customers are significantly larger and will require the full versions of SQL Server and Reporting Services. Even our largest customer will never have more than about 50 users accessing our application at one time. I hope this helps explain the scope and depth of the design issues I am facing. Once again, thanks for any advice anyone cares to offer. -R.B. Davidson
