Каков ваш опыт использования блоков приложений Microsoft? - PullRequest
7 голосов
/ 23 апреля 2009

Каков ваш реальный опыт работы с блоками приложений Microsoft и другими решениями Microsoft, в отличие от написания ваших собственных решений?

Я начал новый проект и решил попробовать. Я использовал блоки обработки исключений и регистрации. Блок обработки исключений хорошо работает для того, что мне нужно. Блок регистрации сделал 95% того, что мне было нужно, остальное нужно было настроить. Потребовалось некоторое время, чтобы понять, как его настроить, а затем возникли некоторые проблемы со ссылками на версии. Ведение журнала - очень простая задача, будь то запись в файл или базу данных (в этом проекте оба). Оглядываясь назад, я бы быстрее написал свою собственную.

Проект также требует синхронизации данных с КПК. После небольшого исследования стало ясно, что направление, на которое указывает Microsoft, - это службы синхронизации. Потратив около 3 дней, пытаясь получить все нужные версии различных программ, я не смог заставить работать образец Ошибка синхронизации Windows Mobile . Я решил использовать простое OpenNETCF Desktop Communication для копирования файлов в / из pda, использования сериализации двоичных объектов и написания собственного базового кода синхронизации, который занимал меньше времени и делал все именно так, как я этого хочу (и не чувствовал хорошо :))

Некоторые позитивы:

  • Не нужно изобретать велосипед
  • Выгоды от обновлений
  • Воспользуйтесь другими инструментами, предназначенными для работы с ними
  • Большая база пользователей увеличивает обратную связь, тестирование и надежность
  • Хорошо иметь в своем резюме
  • Новый разработчик, добавленный в команду, может быть знаком с ними
  • Предоставляет множество настраиваемых функций

негативы:

  • перепроектирован, попытайтесь быть швейцарским армейским ножом, предоставляя намного больше функциональных возможностей, чем когда-либо требовалось для одного решения, создающего сложность.
  • несмотря на это, кажется, что они никогда не отвечают всем требованиям проекта, хвост может в конечном итоге вилять собакой. Я полагаю, это зависит от того, насколько сильно вы влияете на работу приложения.
  • нужно научиться правильно реализовывать блок приложения (хорошо, так что это нужно сделать только при первом использовании, так что это не важно)
  • увеличивает зависимости на разных версиях dll, немного с этим связано
  • большой и громоздкий (на самом деле это не проблема)
  • сложно настроить из-за их сложности

Это был мой опыт обучения, который позволит мне лучше подготовиться к принятию решения о том, использовать ли решение Microsoft (или другие сторонние решения), а не писать свое собственное.

Как насчет вашего опыта?

Ответы [ 8 ]

6 голосов
/ 23 апреля 2009

Они чрезмерно спроектированы , и это была моя самая большая проблема с этим, в конце концов я избавился от этого и больше не использую его.

Они недостаточно полезны, требуют слишком много настроек, изменений в системе, и они постоянно меняют в них вещи. Чтобы просто добавить функцию ведения журнала, вы потратите 2 дня на то, чтобы все было правильно.

Существуют библиотеки, которые работают за 10 минут, как и следовало ожидать.

2 голосов
/ 23 апреля 2009

Я не использовал их много, в первую очередь потому, что что-то более сильное поколебало меня от этого. Например, при работе с исключениями я выбрал CodePlex.Diagnostics, хороший пакет, который регистрирует вещи на SQL Server. Очень просто и полезно для веб-приложения. Для ведения журнала я использую log4net под управлением Log4PostSharp. Конечно, я использую PostSharp вместо PIAB, хотя бы потому, что прекомпиляция по определению быстрее динамических прокси.

Одна классная вещь - это блок приложений Unity: он, похоже, перенял некоторые уроки, извлеченные из других DI-структур, и на самом деле довольно прост в использовании (конечно, есть и PostSharp4Unity).

1 голос
/ 24 апреля 2009

Мы используем Unity с некоторым успехом. Я вообще против контейнеров DI, но если вам нужно использовать один, Unity работает достаточно хорошо.

Я менее убежден в большинстве других. Библиотека журналов, в частности, сводила меня с ума. Огромный и сверхпроектированный, и в то же время жестко закодированный для некоторых конкретных (и упрощенных) сценариев, требующих переопределения глупых объемов кода для фактического расширения библиотеки с некоторыми довольно очевидными функциональными возможностями. И документация схематично о том, как настроить и настроить его, помимо абсолютных основ.

Я тоже не вижу большой пользы в блоке доступа к данным.

В общем, я не большой поклонник.

1 голос
/ 23 апреля 2009

Есть ли у вас одно приложение для обслуживания? Проверьте, может ли вам помочь AB (или любые другие компоненты), протестируйте их и используйте их, если они пройдут проверку, в противном случае - нет.

Есть ли у вас большой и растущий набор приложений для обслуживания? Затем вы либо создадите такой же код для работы, например. ведение журнала, аутентификация и авторизация, удаленная связь и подобные повторяющиеся проблемы (именно то, что зависит от вашего бизнеса и ИТ-среды); сверните свой собственный код или компоненты для решения проблем (и поддерживайте его!); или использовать что-нибудь с полки. Один из этих подходов обычно (если не всегда), как правило, лучше работает с большим количеством приложений и ротацией рабочих мест в вашей компании. Угадай что! (В частности, никогда не стоит недооценивать время, необходимое для подготовки нового разработчика / сопровождающего к продуктивности в приложениях, рассчитанных на более чем 2 года, без схожести или совместного использования компонентов с другими вещами, над которыми они работали раньше!)

Я использовал блоки приложений MS несколько лет назад. В то время блок обработки исключений и блок доступа к базе данных очень помогли; протоколирование AB было достаточно хорошим (хотя я предпочел log4net для его детального управления); и большинство нынешних AB там не было. На мой взгляд, недостатки адреса AB в текущей структуре . Если они успешны (и действительно устраняют существующие болевые точки), вы должны полагать, что они будут перенесены в будущие версии фреймворка или что язык и / или фреймворк будут расширены для непосредственного решения болевых точек.

Код сам по себе никогда не бывает чрезмерно или недостаточно спроектирован, только для определенной цели. Большая проблема с оценкой готовых компонентов заключается в том, чтобы выяснить, какова эта цель на самом деле, в отличие от манифестов о рыночных или чрезмерно оптимистичных принципах «спаси мир и кухню». Группа MS P & P , кажется, далека от групп разработчиков продукта, и иногда решает неправильные проблемы из-за недостаточного понимания последних версий продукта ...

1 голос
/ 23 апреля 2009

Блоки доступа к данным и обработки исключений (я использовал только 2) отлично подходят, если вы не ищете ничего сверх базовых функций из коробки. Конечно, есть и другие более мощные фреймворки, но с минимальной конфигурацией и очень мелкой кривой обучения, вы можете запустить эти 2 блока в кратчайшие сроки.

И поскольку они используют фабричный шаблон, они легко расширяемы, если вам нужно. Мы настроили блок «Обработка исключений», чтобы показывать все виды данных Active Directory вместе с генерируемым исключением. Это сократило наше время поддержки на приличный кусок.

1 голос
/ 23 апреля 2009

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

Я всегда считал, что лучше всего написать свои собственные средства ведения журналов и обработки исключений. Таким образом, я решаю, что будет добавлено и удалено в зависимости от потребностей моего приложения. Что касается изобретения колеса, это меня не сильно беспокоит. Я предпочел бы построить что-то в соответствии со своими спецификациями, а не использовать что-то, построенное в соответствии со спецификациями общего сообщества программистов, которое я должен взломать.

0 голосов
/ 24 апреля 2009

Мы используем блоки регистрации, обработки исключений и проверки.

Мой опыт работы с логгингом AB похож на ваш: он проделывает вам 95% пути. Настройка не легка, и приводит ко всем видам накладных расходов (обновление, тестирование на неизвестной территории, ..). В целом, хотя, я не думаю, что это было бы быстрее, чем я, особенно если учесть, что параметры конфигурации очень удобны (не так сильно во время разработки, но когда они развернуты, мне действительно нравится иметь редактор и включать / выключать) фильтры во время выполнения и т. д.). Я написал небольшую обертку вокруг него, поскольку обнаружил, что он предлагает гораздо больше вариантов, чем нам нужно (например, отдельная серьезность / приоритет - какая разница снова? И т. Д.).

Обработка исключений, которую мы использовали ненадолго, но выбросили. В конечном итоге мы решили, что это слишком большая конфигурация. Конфигурация в app.config имеет серьезную проблему: она не является модульной (то есть вы не можете легко объединить конфигурацию из разных источников).

Валидация: не большой поклонник. Без особой причины, просто не применимо много.

Итак, в конце концов, мы действительно используем только настроенную Logging AB. Сделай вывод о том, насколько все это полезно;)

Так что я бы согласился, что АБ на самом деле не руководство - они предлагают широкий спектр опций, и вам нужно определиться с тем, как его использовать.

У нас был плохой опыт использования CAB (Composite UI AB). К сожалению, мы слишком далеко продвинулись, чтобы изменить его сейчас, но если бы я снова сделал тот же проект, я бы вообще не использовал CAB. Похоже, что это не совсем то, что нам нужно, так что это больше мешает, чем все остальное, и запутывает многое из того, что происходит.

0 голосов
/ 23 апреля 2009

Я не использовал их с .NET 1.1 / раннего .NET 2.0, и он был очень ограничен блоками Application for Data. Честно говоря, я не особо задумывался об использовании чего-либо в последнее время, и я должен посмотреть и посмотреть, что у них есть в настоящее время.

На практике мне было проще написать собственное решение. Как правило, я вижу довольно специфические случаи, и мне приходилось прыгать через несколько обручей, чтобы все работало так, как я хотел. С другой стороны, тогда я занимался большим количеством ASP.NET (что, похоже, в целом связано с веб-разработкой), и сейчас я в основном Windows Applications, что кажется немного более простым.

Я думаю, что это действительно должно быть в каждом конкретном случае. Если это работает для вас и отвечает вашим потребностям, используйте то, что есть. Нет необходимости тратить время на воссоздание чего-либо, когда есть абсолютно жизнеспособное решение. Также нет причин для обновления, если вы не измените версии фреймворка и т. Д., Если они выпустят новую версию DLL. По моему опыту все равно.

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