Рамки приложений - купить, построить или ассимилировать? - PullRequest
3 голосов
/ 07 декабря 2008

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

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

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

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

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

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

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

Мы также приняли некоторые другие функции, как есть. Например, мы используем PostSharp для AOP, moq для насмешки и autofaq для DI.

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

Ответы [ 2 ]

1 голос
/ 07 декабря 2008

Наш подход состоял в том, чтобы посвятить целую команду архитекторов (а именно ' Технические архитекторы ') для:

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

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

1 голос
/ 07 декабря 2008

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

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

...