Issues to consider when choosing data access technologies?

There were times when we had to choose between 2 or 3 technologies/strategies to develop modules.

Now for every small or large component/module/project, we have almost uncountable options. It might be easy for those with years of experience, but not for those who are new to programming, say less than a year.

I get frustrated sometimes with the choices out there for data access in the .NET world. We cannot go and read about every tool there is in the market and what开发者_StackOverflow社区 it has to offer, for each and every product.

The reason for coming up with the question is recently we had to work on a project and specs for the DataAccessLayer were finalized with ADO.NET. About 20% of the way into the project, a new developer joined our department (but not our team). I'd consider him smart, helpful, and we enjoy working with him.

During a code review, he personally advised us that it was better to use LINQ to SQL for the module we were working on. He was convincing. After a positive debate, we agreed to use LINQ to SQL.

However, the "management" was not happy about that. There argument was that we should have come up with this "fantastic idea" before starting the module. Their argument is that resources have been spent on 20% of the work so far, and that work will be wasted.

Given the pace of new products/technologies/strategies coming out frequently, we find it difficult to have all information about all these tools and technologies.

We've had success using ADO.NET. We had an idea about LINQ (in general), NHibrnate and many others, but we went ahead ADO.NET. I am not opposing learning new things, that is the reason we collectively pushed for using LINQ.

Question Are we at fault for making this choice at the time we did?

Are there any metrics or guidelines for making a decision about which to technology choose for certain situations, and when not to switch mid-stream?

Time frame, and project risk. Those are the fundamentals.

I am not familiar in any depth with LINQ or ADO.NET, but that's not important.

At a high level, I can see no difference between LINQ and ADO.NET. I can see LINQ being "better", "more elegant", less code and clearer. But, in truth those are not big project risks if the team is already familiar and comfortable with ADO.NET. You're still going to get your data in and out of the database, and the team already knows how to deal with the "less elegant, more code, less clear" ADO.NET (mind these are generalizations, not judgements per se).

If there's time in the project to be able to absorb the adoption of something like LINQ, and it's demonstrably better even for a new technology, then I can see adopting it for new work, and perhaps retrofitting it in old, done work.

If you have, like, a year long project, its easy to see where there could easily be enough "slack" in the timeline to adopt a new technology. If it's a 1 month project, perhaps not so much.

While there are many wonderful new techs out there, and they are coming out every day, much can be said about wrangling "the devil you know" vs adopting something new and unproven. This is why, personally, I do most of this kind of exploration on my time, at home, in "hobby mode" so that I can be better informed for new projects when a new tech might be suitable and appropriate over our tried and true "old school" methods.

Otherwise, time needs to be made available during project specification to proof new tech to determine its appropriateness for inclusion at project start. Many times, folks making specifications aren't given that time.

It's a challenging, and increasingly more difficult, task to keep all of the current technologies in mind when starting a new project.

I try to always follow whatever is the cutting edge, so that I know what is out there. This is a matter of reading a lot of blogs, attending conferences, and staying current.

That being said, you don't want to always use whatever is on the cutting edge. My rule of thumb is to estimate the ship date of the product. I try to use whatever technology will be the newest to have received at least one "service pack" or update by the date we're going to ship. Granted, this involves a lot of guesswork, since ship dates aren't known, but experience (in watching the industry) helps tremendously.

There's an art to making educated guesses about which technologies will be popular, and which will fall away over time. Unfortunately, that's really a matter of experience. If you have a developer with many years of experience who also stays up to date with current technologies (important), then they are a good resource to help in this decision making.

There are a lot of factors that can weigh in on what technology is "proper" for a given solution or development project.

Many times you are going to have many internal and external influences in regard to options, what seems "right", what is popular, and what might be the most fun.

Making the "proper" decision as I see it is to pick the most stable, documented, workable solution. Now to do this, you need to keep up on technology and know what is out there. So keeping up on LINQ, Entity Framework, etc. is imperative.

The real "art" is deciding what is appropriate for your environment and each environment is different, you have many different items to consider. Is this internally use only? If not, what kind of control and influence do you have over the environment? Is it possible to use the most current version of VS etc.

I am NOT a fan of using the "cuttting-edge" just because that is what it is. There needs to be a technical basis to use the new tools.

To switch to Linq-to-SQL after the project had already begun, and when not everyone was ready, was probably a mistake, yes. Even if you should have used it to begin with, it is better to stick with what you know once a project has started. The reverse is different: If you are trying something new at the beginning of the project and it is going badly, it may be best to switch back to something more familiar.

In the case of Linq-to-sql, it is unlikely that it would give you advantages worth switching to it mid-project. This was a gamble and unfortunately it sounds like it did not work out.

.Net Data Access options are driving many of us crazy. You are not alone. Even trying to know about all the technologies is getting difficult. To properly evaluate you have to have experience and investigate thoroughly. You definitely do not want to try the latest thing because it seems neat. Some of our old familiar technologies (like ADO.NET) work just fine.

With 1 year experience, it is not your fault for not choosing the right technology in the first place. These kind of decisions are hard to take and come with experience.

Who is at fault here is more than likely the project manager for not supplying the right resources to make those architectural decisions at the beginning of the project.

Half the time it feels like it's more about using the resources you have on hand (i.e. what languages do people know?) and what do we have licensed?

Using "LINQ" is not necessarily a "fantastic" idea be it at the beginning or the end of a project. If your team had experience with ADO.NET and had successfully completed the project with that technology then that indeed was the technology you should have used.

Point being that if you have a team that "knows" VB6 inside and out... well guess what... you better like coding VB6.

Use the technologies that the majority of the team are comfortable and knowledgeable in. (Hopefully that's what you're hiring towards.)