Но если я например работаю исполнителем, и вижу как ПМ нанял бесполезного сотрудника, то у меня уже будет понимание, кого лучше не нанимать, и потом, в качестве менеджера я уже не допущу эту ошибку, хотя сам на эти грабли и не наступал.
Полностью несогласен, что надо провалить проект, взять ненужного человека и т.д. чтобы стать настоящим менеджером. Все таки дураки на своих ошибках учатся, а умные на чужих.
Ну вы мне прямо настроение подняли :-). Сейчас работаю в большой организации, с женой ждем ребенка и начинаю параллельно работать на пол ставки во фрилансе.
Насколько я понял, в их новом ORM запросы пишутся на SQL, так что основной движок больше не на Linq2SQL. А Linq2SQL оставлен для мест, где не требуется высокая производительность.
Тогда получается, что в одном и том же интерфейсе у вас будет и UserSpecificField и AdminSpecifiField. Что противоречит одному из принципов S.O.L.I.D, а именно Interface segregation principle.
Вы должно быть подумали, что я предлагаю добавлять в домен такие вещи как, например, IsUserLocationVisible, которые служат исключительно для того, чтобы определить показывать местоположение юзера на сайте или нет. Если добавить это поле в домен, то конечно же домен начинает зависить от View. И это будет костылем. Вы бы, я так полагаю, добавили это поле во ViewModel.
Я же предлагаю следующее, формализовать то бизнес-правило, на основании которого определяется показывать юзера на сайте или нет и внести его в домен. Допустим нам нужно показывать местоположение юзера, только если он дружелюбный, тогда в домене это будет поле IsFriendly с некой логикой внутри. Которое никаким образом не связано с UI. И на основании уже этого поля определять во View показывать его или нет.
В итоге, я хочу сказать, что вместо того чтобы добавлять поле IsUserLocationVisible во ViewModel лучше добавить в домен IsFriendly.
Разумеется не должен, я этого и не говорил. Я сказал что если вы не можете смаппить домен на вью, то есть 2 варианта решения, пересмотреть домен, или делать костыли в виде ViewModel, которые по-сути раздувают домен со всех сторон.
Полностью согласен. Еще обычно в таких проектах на 30 форм получается куча интерфейсов, репозиториев и сервисов, которые в итоге сводятся к простому селекту в базе данных.
Да, я понимаю что домен может разойтись с отображением. И тогда у вас будет 2 варианта: либо делать DTO, либо пересматривать домен. Мне кажется, что лучше изменить домен.
А зачем прямо уж на каждую страницу создавать ViewModel? Я правда не вижу выгоды. У вас же есть домен, в нем есть User, которого с тем же успехом можно использовать во View. И в нем же можно прописать правила валидации. Особенно если используется CodeFirst модель.
То есть я хочу сказать, что упор надо делать на домен, а не на ViewModel, тогда и работы меньше придется делать и модель будет очевидней.
Например тот же SCRUM четко не регламентирует роли. Так что если есть архитектор хорошо, нету — тоже хорошо. Его может не быть, если все девелоперы являются по праву сеньорами. Если это не так, то без архитектора такого нагородят.
Про инспекцию кода тоже самое.
Спецификацию можно фиксировать в виде комментов к задаче. Лучше так, чем совсем никак. Потом никому ничего не докажете. Я имею ввиду тестеровщику, ПМу, аналитику и т.д.
Вещи типа ДАЛа, расслоения системы, архитектуры контролов лучше все же продумать заранее.
Тогда это действительно неплохое решение, если подсовывать этот интерфейс в PartialView.
Я же предлагаю следующее, формализовать то бизнес-правило, на основании которого определяется показывать юзера на сайте или нет и внести его в домен. Допустим нам нужно показывать местоположение юзера, только если он дружелюбный, тогда в домене это будет поле IsFriendly с некой логикой внутри. Которое никаким образом не связано с UI. И на основании уже этого поля определять во View показывать его или нет.
В итоге, я хочу сказать, что вместо того чтобы добавлять поле IsUserLocationVisible во ViewModel лучше добавить в домен IsFriendly.
То есть я хочу сказать, что упор надо делать на домен, а не на ViewModel, тогда и работы меньше придется делать и модель будет очевидней.
Будет интересно посмотреть архитектуру, люблю покодревьюить большие опен-сурс проекты. Всегда есть что почерпнуть для себя.
Про инспекцию кода тоже самое.
Спецификацию можно фиксировать в виде комментов к задаче. Лучше так, чем совсем никак. Потом никому ничего не докажете. Я имею ввиду тестеровщику, ПМу, аналитику и т.д.
Вещи типа ДАЛа, расслоения системы, архитектуры контролов лучше все же продумать заранее.