Putting forward a solution to replace Typed datasets

开发者_运维百科A project I am currently employed with will have some time soon to improve and specialise a product that is currently in use. We may have about 4 man weeks spare in which we could replace the typed datasets that are in use.

The project is currently written in Vb.Net and we will definitely not have time to replace this code with C#.Net, although we would like to.

My question is what would you suggest as a replacement for the typed datasets.

I have currently suggested nHibernate as I have worked with Hibernate before and loved it.

Linq to SQL has been discounted.

So if you can suggest something else/better or highlight what advantages or disadvantages with regards to our current time constraints please do!

Considering your time constraints Linq to SQL (despite being deprecated) would have been ideal. While NH or EF4 are more complete and flexible ORM solutions they do require more consideration of mappings than does a simple drag and drop from the Server Explorer connection mapping onto LINQ to SQL designer and simple instantiation of a DataContext object.

If you don't have the time to get everyone up to speed on an ORM with a future why eliminate the typed datasets at all?

Performance wise they are probably close to identical to what you would be able to get out of an ORM. The benefit of replacement would be maintainability and developer pleasure, both of which would be <warning:shameless plug for personal preference> accompanied by a C# rewrite at the same time...

I think NHibernate is a good choice to replace typed datasets, I just successfully did that on a project I was on recently. I wouldn't do a "big bang" approach though. I would write new features using NHibernate and maintain old features using typed datasets. Once the new features are working well with NHibernate and you have the appropriate usage patterns in place, I would carefully transition the typed dataset and sproc code to use NHibernate instead. The speed at which you do the replacement doesn't really matter, just move at a comfortable pace.

Big bang is always a highly risky approach and incremental progress is easier for everyone to swallow.

I honestly don't see a compelling reason to switch a project in production from VB.NET to C#, there are so few meaningful differences and it helps to have VB.NET (in addition to C#) experience on your resume.

I would not encourage use of LinqToSql nor would I encourage use of Entity Framework 3.5. EF 4 may be a reasonable option using the same incremental approach.