TypeScript — язык со статической типизацией. Но без поддержки рантайма и библиотек — мало что выйдет. Хотя сделать тип Array в TS принципиально ничего не мешает.
В том то и дело, что не составляется граф. Потому что внутренняя реализация может меняться довольно сильно, а потоки данных относительно стабильны. Кроме того не каждая задача хорошо описывается автоматом.
WCF DataServices работает с контекстом EF. Так что все равно сколько, хоть 100 будет. Форматтеры как обычно: atompub и json, встренные, вроде может можно поменять. Пользователей десятки-сотни были, полет нормальный. На фоне IO базы и передачи данных по сети сериализация\десерилизация не видна.
В последней версии Odata научили передавать проекции, так что сериализатор теперь никакой роли не играет по сути, важнее правильные запросы делать.
Если вся система сводится к CRUD, то эта техника работает. Но лучше в этой ситуации работает access ;)
Если система не сводится к CRUD, то такую матрицу нарисовать сложно. Есть способы получше. Например так:
Для каждой функциональности можно посчитать количество «входов и выходов» (входы и выходы это необязательно сущности), потом умножить на коэффициент «сложности» для модуля. Например контроллер в веб-приложении сделать это один коэффициент, а windows-сервис — другой.
Таким образом можно получать объективные и достаточно точные оценки объема.
Это зависит от запросов, можно неаккуратно писать и упереться в в одну общую таблицу сущностей, если действовать по модели, предложенной в статье. Разные таблицы для разных типов (3НФ) конечно приближает к идеалу, но её сложно поддерживать.
Еще обязательно рассмотреть такие моменты:
1) создание связей между произвольными типами
2) версионность документов
3) «корзина» удаленных элементов
4) разграничение доступа
Системы валятся от объема данных не потому что подставь_сюда_любой_движок_БД слабоват, а потому что изначально не продумывали аспекты, которые я указал выше, а потом они «внезапно» возникли.
Нагрузка для корпоративных приложений измеряется объемами обрабатываемых данных. В типичной учетной системе необходимо быстро и стабильно работать при 1М+ проводках и при 100,000 первичных документов.
Посчитать легко. Берем цикл жизни системы — 5-9 лет — умножаем на количество первичных документов и проводок в год, умножаем на Пи (оно примерно равно 15%-росту в год на все 9 лет). Получаем требуемые числа.
Ограничение прав пользователя в базе + Надежный пароль + SSL (если БД поддерживает), почему нет?
При использовании excel services как раз не надо давать пользователям сам документ, только данные \диаграммы из него. В onpremise можно настроить обновление на сервере, без открытия самого документа.
Начнем сначала, чтобы были «on the same page». Есть стратегия обеспечения качества, описанная во множестве методологий. Например для кода: проведение ревью, тестирование, устранение ошибок перед разработкой нового функционала. Для интерфейса: проработка сценариев использования, usability тестирование. И так далее.
Во многих стартапах бытует мнение что можно забить на ревью и тестирование, сделать интерфейсы абы-как, а потом допилить на основе результатов использования. Новый функционал пушится чтобы успеть к сроку релиза. В итоге это все приводит к том, что к планируемому сроку функционал не готов, все падает, использовать неудобно. То есть фактически продукт не готов для использования.
Именно об этом и пишет Роберт Мартин, правда он взял для примера очень спорный вопрос — TDD. Но в целом он более чем прав.
При этом никто не договорит что нужно добавиться максимального качества, это скорее вредно, чем полезно. Но вот минимальный уровень качества обеспечить необходимо, и для этого есть довольно мало способов и нету никаких обходных путей.
ОМГ зачем это все? Excel умеет втягивать данные из любого ODBC-совместимого источника. Никаких WCF, IIS не нужно.
Одним GET запросом можно забрать данные из Excel на стороне PHP, еще два запроса нужны для авторизации.
Недостаток — обновлять данные надо ручками (макросом, скриптом на VBS), o365 не умеет сам обновлять внешние данные в excel, только в on-premise варианте.
Это все имеет смысл если расчеты сложнее одной функции агрегации, типа sum или avg. Я знаю проекты, которые на таком ad-hoc решении прожили довольно долго.
В последней версии Odata научили передавать проекции, так что сериализатор теперь никакой роли не играет по сути, важнее правильные запросы делать.
А недавно коллегами было сделано iOS приложение, которое работает с WebAPI и похожее, которое работает с OData.
Если система не сводится к CRUD, то такую матрицу нарисовать сложно. Есть способы получше. Например так:
Для каждой функциональности можно посчитать количество «входов и выходов» (входы и выходы это необязательно сущности), потом умножить на коэффициент «сложности» для модуля. Например контроллер в веб-приложении сделать это один коэффициент, а windows-сервис — другой.
Таким образом можно получать объективные и достаточно точные оценки объема.
Еще обязательно рассмотреть такие моменты:
1) создание связей между произвольными типами
2) версионность документов
3) «корзина» удаленных элементов
4) разграничение доступа
Системы валятся от объема данных не потому что подставь_сюда_любой_движок_БД слабоват, а потому что изначально не продумывали аспекты, которые я указал выше, а потом они «внезапно» возникли.
Посчитать легко. Берем цикл жизни системы — 5-9 лет — умножаем на количество первичных документов и проводок в год, умножаем на Пи (оно примерно равно 15%-росту в год на все 9 лет). Получаем требуемые числа.
При использовании excel services как раз не надо давать пользователям сам документ, только данные \диаграммы из него. В onpremise можно настроить обновление на сервере, без открытия самого документа.
Во многих стартапах бытует мнение что можно забить на ревью и тестирование, сделать интерфейсы абы-как, а потом допилить на основе результатов использования. Новый функционал пушится чтобы успеть к сроку релиза. В итоге это все приводит к том, что к планируемому сроку функционал не готов, все падает, использовать неудобно. То есть фактически продукт не готов для использования.
Именно об этом и пишет Роберт Мартин, правда он взял для примера очень спорный вопрос — TDD. Но в целом он более чем прав.
При этом никто не договорит что нужно добавиться максимального качества, это скорее вредно, чем полезно. Но вот минимальный уровень качества обеспечить необходимо, и для этого есть довольно мало способов и нету никаких обходных путей.
Одним GET запросом можно забрать данные из Excel на стороне PHP, еще два запроса нужны для авторизации.
Недостаток — обновлять данные надо ручками (макросом, скриптом на VBS), o365 не умеет сам обновлять внешние данные в excel, только в on-premise варианте.
Это все имеет смысл если расчеты сложнее одной функции агрегации, типа sum или avg. Я знаю проекты, которые на таком ad-hoc решении прожили довольно долго.