Рамки приложений - покупка, сборка или ассимиляция?

Question

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

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

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

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

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

Несколько примеров вещей, которые находятся в нашей инфраструктуре:

• исключений и регистрации событий провайдеров. Простой, единообразный способ, с помощью которого каждое приложение может регистрировать исключения и события одинаковым образом с минимальным усилием кодирования. Из коробки он может подключаться к SQL Server, текстовому файлу, средству просмотра событий и т. Д. Он содержит точки расширяемости для входа в другие источники.
• Применения с переменным назначением. Общий класс, который предоставляет методы расширения, основанные на типе объекта, используя синтаксис, вдохновленный JUnit. Например, чтобы определить, не является ли myObject непустым, мы можем сделать простой Enforce.That (myObject) .IsNotNull(); или определить, является ли он конкретным типом, выполнив простой Enforce.That (myObject) .IsOfType (typeof (Hashtable)); Ошибки принудительного исполнения поднимают соответствующее исключение, уменьшая количество кода и обеспечивая согласованность в реализации.
• Помощники для тестирования модулей. Серия классов, основанная на отражении, которая может автоматически тестировать классы и их свойства. (Вдохновленный Automatic Class Tester от CodePlex), но написанный с нуля. Помогает упростить создание модульных тестов для вещей, которые традиционно трудны или требуют много времени для тестирования.

У нас также есть некоторые другие функции, как есть. Например, мы используем PostSharp для АОП, moq для издевательств, и autofaq для DI.

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

Answer 1

Наш подход был посвятить целую команду архитекторов (а именно «Technical Architects») для:

• либо адаптировать существующие рамки с открытым исходным кодом, в некоторых случаях их инкапсуляции в API в доме для того, чтобы быть в состоянии изменить структуру, если необходимо,
• или создание новой структуры, основанной на конкретных потребностях, было найдено несколько команд для нескольких проектов.

Каким бы ни был подход, эти рамки должны быть очень хорошо документированы (по крайней мере, с полным public API), и их освобождение должны быть хорошо рекламируется:
Поскольку все команды на основе их работы на этих рамках, они необходимо как можно скорее обновить свои версии инфраструктуры, чтобы строить свои собственные поставки.

Answer 2

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

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