Каковы плюсы и минусы использования компонентов Visual Studio designer для данных

Я наследую кучу программ на работе, где исходный автор использовал компоненты данных Microsoft Visual Studio (где набор данных, адаптер данных и т. д.) создаются внутри среды разработки (из панели инструментов или с помощью мастеров). Это дает некоторые полу-адаптированные (специализированные для данных) классы, а также помещает код SQL в классы, созданные дизайнером.

Это не то, как я привык делать вещи (я всегда предпочитал либо однозначно иметь набор данных, либо создайте свой собственный специализированный класс для хранения данных и скрытия сложности базового слоя данных).

есть ли у кого-нибудь хорошее понимание или ссылки, обсуждающие плюсы и минусы использования компонентов данных Visual Studio?

(Примечание, оригинальный автор также не комментировал очень тщательно и написал, на мой вкус, слишком много "умного" кода, который нелегко интерпретировать, поэтому я не склонен думать, что он знает лучше, чем я)

небось другой способ спросить: приводит ли использование компонентов конструктора данных к коду, который "следует лучшим практикам" и доступен для обслуживания и т. д.? Мне так не кажется, но я ищу мнения экспертов.

[EDIT: добавлен дополнительный контекст для уточнения намерения]

Если я прав (и похоже, что я) об использовании дизайнерских компонентов действительно лучше всего подходит для прототипов и т. д., то мне придется пойти на некоторые жесткие разговоры с оригинальные разработчики, и мой менеджер. Поэтому я хотел бы добавить больше внимания к части "ссылки, обсуждающие плюсы и минусы" моего вопроса... Я ищу что-то существенное, что я могу использовать для поддержки моих утверждений, что этот стиль разработки / кода не является наиболее подходящим для использования в производстве... Спасибо.

7
design visual-studio

4 ответов

в целом визуальные компоненты предназначены для одноразовых приложений, приложений POC и spike, т. е. прототипирования. Это по нескольким причинам; они очень быстро собраться, но полный кошмар для поддержания. Я не уверен в размере вашего приложения, но если бы это был я, я бы утверждал, что в его текущей форме стоимость владения будет увеличиваться со временем и, следовательно, будет выглядеть более DDD-стилем разработки. Bin слой данных и заменить его хорошим твердым телом ORM; NHibernate (предпочтительно) или Entity Framework 4 (легче попасть). Брось умным кодом и начать использовать поцелуй, Ягни, сухая мантра. Это может быть трудно заставить их увидеть свет, но как только он начинает стоить меньше, они будут любить вас за это;)

Если вы хотите больше читать в этой области, посмотрите на следующее:

  1. Навык Дело являются учебным заведением, которое запускает открытую сессию и нагрузки подкаста вы можете смотреть
  2. хорошая книга для обоих разработчиков и менеджеров, чтобы читать это корабль, Он смотрит на хорошие практики проект. Как и все на прагматичной книжной полке
  3. Мартин ловящих блог для всего DDD
  4. Ayende блог отличное место для всех вещей NHibernate
  5. stackoverflow.com это место камни
3

VS цель компонентов данных-быстрая разработка приложений. С этой точки зрения вы можете увидеть его плюсы и минусы:

плюсы: быстрое развитие, не требует много кодирования и знаний. Хорош для небольших приложений, которые не будут изменены в будущем.

минусы: ломает логику дизайна приложения слоя (добавьте сюда все плюсы такого дизайна), объединяя все в один файл. В результате практически невозможно динамически заменить источник данных. Усложняет поддержку больших приложений. DI, TDD-это что-то таинственное, использующее его.

на самом деле это очень широкий вопрос. Я бы рекомендовал прочитать больше о разработке приложений N-уровня и тестовой разработке

надеюсь, что это поможет

1

Я бы даже не зашел так далеко, чтобы сказать, что компоненты дизайнерской БД хороши для POCs или прототипирования. Эти компоненты находятся в Visual Studio в основном как шаг продаж для платформы, так что Microsoft может сказать: "Вау, посмотрите, как легко создать приложение, управляемое данными с .NET!" Они должны были быть удалены много лет назад, ИМХО.

однако не путайте компоненты конструктора с ADO.NET (т. е. DataTables, DataSets, DataReaders, DataAdapters etc.) сам. Поскольку приложение, которое вы унаследовали, было построено вокруг компонентов дизайнера, что означает, что оно также было фундаментально построено вокруг ADO.NET компоненты. Вы можете (и должны) избавиться от designer components, но вы не обязательно должны избавиться от ADO.NET -тоже.

1

Я лично думаю, что вы определенно на правильном пути, но имхо это действительно зависит от того, что у вас уже есть и какие планы на будущее продукта.

Я видел производственный код, который использует так же, как вы говорите, и работает нормально, и несколько легко ремонтируется. Есть даже большое падение модулей от очень крупных компаний, таких как Telerik, которые попадают в ту же категорию разработки, о которой вы говорите.

I подумайте, что действительно является важным фактором для вашего работодателя: что вы можете использовать, чтобы получить работу самым быстрым и эффективным способом. Я бы сказал, что в целом, хотя, инструменты "перетаскивания" прямо из коробки не очень хороши для долгосрочных приложений корпоративного уровня.

вот статья Чарльза Петцольда, которая может предоставить больше" экспертных " учетных данных для вы.

http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

0