Выдвижение решения заменить типизированные наборы данных

Question

В проекте, в котором я сейчас работаю, скоро будет время для улучшения и специализации продукта, который используется в настоящее время. У нас может быть около 4 человеко-недель, в течение которых мы могли бы заменить используемые наборы данных.

Проект в настоящее время написан на Vb.Net, и у нас точно не будет времени заменить этот код на C # .Net, хотя мы бы хотели.

Мой вопрос: что бы вы предложили в качестве замены набранных наборов данных?

В настоящее время я предложил nHibernate, так как раньше работал с Hibernate и мне это понравилось.

Linq to SQL был сброшен.

Так что, если вы можете предложить что-то еще / лучше или выделить, какие преимущества или недостатки в отношении наших текущих временных ограничений, сделайте, пожалуйста!

Answer 1

Учитывая ваши временные ограничения, Linq to SQL (несмотря на то, что он устарел) был бы идеальным.Хотя NH или EF4 являются более полными и гибкими решениями ORM, они требуют большего внимания к сопоставлениям, чем простое перетаскивание из сопоставления соединения обозревателя сервера в конструктор LINQ to SQL и простое создание экземпляра объекта DataContext.

Если у вас нет времени, чтобы все успели освоить ORM в будущем, зачем вообще исключать типизированные наборы данных?

С точки зрения производительности они, вероятно, близки к тому, что вы могли бы получитьвне ОРМ.Преимуществом замены будет удобство сопровождения и удовольствие разработчика, оба из которых будут <warning:shameless plug for personal preference> сопровождаться перезаписью на C # одновременно ...

Answer 2

Я думаю, что NHibernate является хорошим выбором для замены типизированных наборов данных, я только что успешно сделал это в проекте, над которым я недавно работал. Я бы не стал подходить к «большому взрыву». Я написал бы новые функции, используя NHibernate, и поддерживал старые функции, используя типизированные наборы данных. Как только новые функции хорошо работают с NHibernate и у вас есть соответствующие шаблоны использования, я бы осторожно перевел типизированный набор данных и код sproc на использование NHibernate. Скорость, с которой вы выполняете замену, на самом деле не имеет значения, просто двигайтесь в удобном темпе.

Большой взрыв всегда очень рискованный подход, и постепенный прогресс легче проглотить.

Честно говоря, я не вижу веской причины для переключения проекта в производстве с VB.NET на C #, так как в нем так мало существенных различий, и это помогает иметь опыт работы с VB.NET (в дополнение к C #).

Я бы не поощрял использование LinqToSql и не поощрял использование Entity Framework 3.5. EF 4 может быть разумным вариантом, использующим тот же инкрементальный подход.