ABP vs Asp.net Boilerplate - Текущее состояние производства

Я собираюсь приступить к реализации нескольких проектов мультитенантных приложений и серьезно смотрю на ABP и ASP.NET Boilerplate в качестве отправной точки. Поскольку у меня есть этот редкий шанс начать все заново, я, очевидно, хотел бы использовать последнюю и лучшую (ABP), но кажется, что ABP не хватает МНОГО документации - система событий, электронная почта, как заполнить данные и т. Д. - везде, где я иду Я вижу ДОЛЖНОСТЬ в документации, и это заставляет меня задаться вопросом, сколько людей разрабатывают с ее помощью новые проекты. Действительно ли люди (которые ранее не разрабатывали решение ASP.NET Boilerplate) используют ABP? Как вы решаете все дыры в документации? Имея такую ​​лучшую основу, каковы реальные недостатки использования ASP.NET Boilerplate?

Спасибо, Дэйв


abp
person David Collom    schedule 25.04.2020    source источник

Ответы (2)


arrow_upward
2
arrow_downward

У меня был некоторый опыт работы с фреймворками Boilerplate, такими как ABP и DNN и т. Д. По моему опыту, краткосрочные выгоды от использования этих монолитных фреймворков не стоят тех затрат, которые они понесут позже в течение срока службы решения.

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

Однако в конечном итоге они увязли со слишком большим мертвым грузом.

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

person Retic    schedule 28.07.2020
comment
сам фреймворк в основном ориентирован на веб-уровень (своего рода шлюз), есть много компонентов, которые вам нужно написать самостоятельно, если вы не используете фреймворк, в том числе: кеширование, проверка, доступ к данным, авторизация ... Они могут стоить одному разработчику в месяц или более, чтобы завершить базовую кодовую базу для разработки. Также, когда дело доходит до команды, знакомство с кодом другого участника (обычно лидера) может быть сложной задачей (из-за качества кода, отсутствия документации ...) для других участников. Так что использование фреймворка в таком случае может быть хорошим выбором ... - person Hopeless; 18.11.2020
comment
с целью масштабирования приложения, я считаю, что оно почти лежит на нижнем уровне (а не на веб-уровне), а точнее на уровне обслуживания, который можно запускать на нескольких независимых хостах. Даже шлюз можно масштабировать. Все компоненты, о которых я упоминал выше, обычно помещаются в один монолит, потому что они принадлежат уровню шлюза. Таким образом, веб-фреймворк здесь является монолитным, но это не все решение и, конечно же, его можно использовать, даже если он должен быть масштабируемым и модульным. - person Hopeless; 18.11.2020

arrow_upward
1
arrow_downward

В январе прошлого года у меня была возможность использовать ASP.NET BOILERPLATE с сетевым фреймворком, а затем (10 месяцев назад) в проекте сетевого ядра. Затем, 5 месяцев назад, появился новый проект сетевого ядра, и мы скептически относились к безумию ABP, но вместо этого мы перешли к нему, потому что он был рекомендован для сетевого ядра, несмотря на то, что большая часть документации была пустой. Это было хорошее решение, если вы раньше использовали ASP.NET BOILERPLATE или начинаете проект сетевого ядра, я настоятельно рекомендую начать с платформы APB (они много оптимизируют для сетевого ядра). Каждую неделю они выпускают новую документацию, выпускают версии очень быстро, а на их странице проблем с github есть много документации из вопросов других пользователей (сообщество быстро растет).

person luispadilla_vecl    schedule 28.05.2020