Каково Ваше мнение о MS CAB (Блок Составного приложения)?

Уже существует похожий (идентичный?) вопрос , с очень хорошим ответом , который также решает мою проблему.

В основном мне нужно сделать следующее:

git rev-parse --verify bf450342272a94117d78eae34a140a2a39359dad > .git/info/grafts
git filter-branch -f -- --all 

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

Тогда репо будет unshallowed / ungrafted, и его можно будет обычно отправлять на новые пульты с уменьшенной историей.

6
задан Brann 25 January 2009 в 14:11
поделиться

4 ответа

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

Jeremy Miller записал превосходную серию сообщений в блоге о создании Вашего собственного CAB

http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-own-cab-series-table-of-contents.aspx

это достойное внимания, поскольку Вы могли просто взять оттуда, в чем Вы нуждаетесь.

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

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

7
ответ дан 9 December 2019 в 20:50
поделиться

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

0
ответ дан 9 December 2019 в 20:50
поделиться

CAB отменен в пользу SCSF . И CAB, и SCSF предлагают некоторую ценность с точки зрения стандартизации разработки полнофункциональных клиентов для разных проектов (если вы используете их таким образом), но оба они очень тяжелые.

1
ответ дан 9 December 2019 в 20:50
поделиться

We have used CAB+SCSF for a couple of projects. The learning curve is indeed steep. You will probably be up to speed after the first month. Other cons:

  1. Too much complexity
  2. Pattern-itis
  3. Code generation bloat
  4. Hard to debug

The pros:

Follows the best practices architectural design patterns in the industry:

  1. Model-View-Presenter
  2. UI Composition
  3. Dependency injection, Inversion of control
  4. Loosely Coupled Events
  5. Modularity
  6. etc...

Using CAB-SCSF in the long run will mean less bugs and more maintainable code. If your project can afford the initial hit of the learning curve I will definitely recommend it.

4
ответ дан 9 December 2019 в 20:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: