Виктор Бузин

Тут задача расширенная и не особо тривиальная, тут лучше исходить из того, должно ли это работать на земле или в облаке? Если на земле, что очевидно то я бы посмотрел в сторону своего основного сервиса или приемника сервиса + esb в лице MS Message bus который выступает в виде шины к системам а за ним серию интерфейсов которые уже осуществляют сериализацию и CRUD модель. Про bus, хорошо описано здесь:https://m.habrahabr.ru/post/254059/

Что касается SharePoint, то лучше слизывать CSOM и его асинхронные преимущества.

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

Еще добавлю чутка. Сам делал недавно проект на mvc и есть такие вещи как "Unit of Work" и прямое разделение на слои приложения и как раз в сервисном слое без интерфейсов никак. Ну и как ранее упомянули полиморфизм и ООП. Если ничего этого не делать, то в итоге можно получить на добротном проекте большую какаху. Конечно в мелких проектах можно и без них, но мы все и сами знаем что все маленькое это только старт для заказчика и можно просто взять фальшстарт, а потом затрахаться с покрытием тестами т.к. Придется переписывать и пропадает расширяемость. А если там еще будет замута с сервисами в Azure то все вилы, так что делаем выводы и пытаемся сразу стартовать правильно.

Я бы использовал OfficeOpenXML + EPPlus небольшой сахар для OOX. Попробуй, там все просто.

Вы можете добавить все во ViewModel и вынести туда логики, так в основном и делают в контроллерах только выбрасывание данных, потом в ViewModel агрегируем и актуализируем данные и на форму выплескиваем.

По большому счету, по моему большому и тернистому опыту разработки SharePoint, а о нем я могу сказать с 2003 версии, то что сейчас есть 2013 версии это летающий танк у которого есть очень многое и до разработки именно кастомных решений может просто не дойти. Он достаточно богат на функционал, если разобраться и out-the-box имеет много корпоративных плюшек. Но есть большое НО, в России менджмент и топ менеджмент компаний очень любит все нафиг переделать или запилить ему дизайн и т.д., вот тогда и начинается АД с большой буквы т.к. наращивать функционал ( даже кастомный) в рамках дефолтного UI проще и дешевле.

Что касается MVC, то вам придется этот летающий танк собрать самому типа DYI =) А с SP он у вас уже есть, просто надо прочитать инструкцию по применению и примеры адаптации той или иной фичи и там дальше по обстановке.

Если выбрали Angular, значит были на это причины, все мы знаем Angular не супер крутой, только по началу кажется что там космос, но есть и обратная сторона луны стоит только сделать более сложную логику в сторону настоящего MVVM или MV* и начинается. По MVC даже с WebAPI или OData вы все равно будет работать с бэкендом и это будет ASP.NET, а то что на клиенте не имеет никакого значения Angular, Breezejs, React... потом просто стоимость перехода на другой клиентский "Фреймворк" будет очень дорогой. Razor в некоторых моментах тоже хорошо делает свою работу.

Ну если декомпелировать сборку, то можно и попробовать убрать и это будет реальный квест. По бесплатным решениям работы с офисными доками, всегда юзал OpenXML SDK хардкорно но зато легковесно и точно в цель, потом напишешь свой Spire.XLS to HTML т.к. все эти сборки в основном использую OpenXML SDK. Как то так.