Унификация уменьшает порог вхождения нового сотрудника, в этом нет ничего плохого.
То, разделение что вы привели, я тоже не увидел предметной области. Видимо она спрятана в «т.д.» У меня в проекте вся логика предметной области находится в отдельном слое. Бизнес-сущности-модели отделены от «технических» моделей. Про «одни и теже вложенные каталоги» с таким не сталкивался, во всём солюшене у меня один класс User, а никак не несколько в разных подпроектах.
Подпроекты между собой должны быть связаны, эта связь и определяет конечный продукт. Но связь должна быть слабой, через DI, чтобы изменения одного подпроекта не были фатальными для других частей.
Если проект становится сложно сопровождать, то видимо вылезают ошибки архитектуры.
Пару лет использую anemic model и жизнь стала проще :)
Энтерпрайз решениям важно движение данных и их история, которое лучше всего делается на анемичном домене. ООП в чистом виде — для работы с состояниям объектов, для игр это лучший вариант. Каждой задаче свой инструмент.
Одно дело когда собственник пишет конрагенту о смене директора и приостановке платежей до конкретной даты. И совсем иное отношение когда компания втихую не платит. Если собственник не знает о долге, то как ему дать знать об этом? Весь вопрос в наличии контактов собственника у контрагента, т.к. связь через директора похоже оборвалась.
Меня наверно закидают тапками, но считаю что тут переизбыток ООП. В частности я бы выкинул все билдеры, кроме CalendarViewModelBuilder.
Причина — я не верю что на практике будет переиспользован DayViewModelBuilder. Если будет какой-то новый CalendarVisitorsViewModel, то вместо DayViewModel будет использоваться новый DayVisitorsViewModel в котором скорее вместо IEnumerable EventViewModel будет IEnumerable VisitorsDayStats А разбираться что делает билдер внутри билдера, который внутри третьего билдера ради гипотетической возможности переиспользования в будущем как-то не хочется.
Однажды нашел плагин для браузера, позволял ввести xpath и подсветить найденные элементы на открытой странице. Но после переустановки системы не могу его снова найти, те что находятся через поиск хрень какая-то. Может в своей практике находили нормальный?
Поэтому в дебаге минифкация должна быть отключена, а при выполнении publish в VS проект должен собраться в релизе, все скрипты должны упаковаться и всё это выкатится на препрод сервер.
Это не академический интерес, это реальный процесс разработки и он должен быть автоматизирован, а не в консоли набирать команды каждый раз.
Схема неполная. Основная идея — автоматизированная отчётность хотя бы ежедневно. Если данные из системы будут отличаться от прогнозных, то надо будет разбираться в чём причина, или модель некорректна, или данные недостоверны (чёрная бухгалтерия и т.п. налоговые оптимизации), или есть элементы прямого саботажа.
href="/"
То, разделение что вы привели, я тоже не увидел предметной области. Видимо она спрятана в «т.д.» У меня в проекте вся логика предметной области находится в отдельном слое. Бизнес-сущности-модели отделены от «технических» моделей. Про «одни и теже вложенные каталоги» с таким не сталкивался, во всём солюшене у меня один класс User, а никак не несколько в разных подпроектах.
Подпроекты между собой должны быть связаны, эта связь и определяет конечный продукт. Но связь должна быть слабой, через DI, чтобы изменения одного подпроекта не были фатальными для других частей.
Если проект становится сложно сопровождать, то видимо вылезают ошибки архитектуры.
Энтерпрайз решениям важно движение данных и их история, которое лучше всего делается на анемичном домене. ООП в чистом виде — для работы с состояниям объектов, для игр это лучший вариант. Каждой задаче свой инструмент.
Причина — я не верю что на практике будет переиспользован DayViewModelBuilder. Если будет какой-то новый CalendarVisitorsViewModel, то вместо DayViewModel будет использоваться новый DayVisitorsViewModel в котором скорее вместо IEnumerable EventViewModel будет IEnumerable VisitorsDayStats А разбираться что делает билдер внутри билдера, который внутри третьего билдера ради гипотетической возможности переиспользования в будущем как-то не хочется.
Увидел только про TeamCity.
Если есть опыт использования с CI, то расскажите — неглючно, информативно?
И как от этого защищает не DV сертификат? Особенно если пользователь уже зашёл на этот похожий домен?
Вот не надо меня отвлекать.
Поэтому в дебаге минифкация должна быть отключена, а при выполнении publish в VS проект должен собраться в релизе, все скрипты должны упаковаться и всё это выкатится на препрод сервер.
Это не академический интерес, это реальный процесс разработки и он должен быть автоматизирован, а не в консоли набирать команды каждый раз.
Чтобы автоматом потом скомпилировался нужный геттер и сеттер с RaiseAndSetIfChanged.
Очень уж много однообразного кода.