Каков Ваш опыт Microsoft Application Blocks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We're using logging, exception handling and validation blocks.

My experience with the logging AB has been similar to yours: it gets you 95% of the way there. Customizing is not easy, and leads to all kinds of overhead (updating, testing on unknown territory,..). Overall though, I don't think it would've been faster rolling my own, especially since the configuration options come in very handy (not so much during development, but when it's deployed, I really like having the editor and turning on/off filters at runtime etc). I did write a little wrapper around it, as I've found it offered lots more options than we needed (e.g. separate severity/priority - what's the difference again? etc).

Exception handling we used for a short while but threw it out. Ultimately we tought it was too much configuration. Configuration in app.config has a major issue: it's not modular (i.e. you can't easily merge configuration coming from different sources).

Validation: not a big fan. For no particular reason, just wasn't applicable much.

So, in the end, we only really use a customized Logging AB. Draw your onw conclusion on how useful the whole thing is ;)

So I would agree that the AB's are not really guidance - they offer a wide range of options and you need to make up your own mind on how to use it.

We've had bad experience using CAB (Composite UI AB). Unfortunately we're too far along to change it now, but if I would do the same project again, I wouldn't use CAB at all. It just doesn't seem to do quite what we need, so it's more in the way than anything else, and it obfuscates a lot of what's going on.