skyANAНемоКэп42А у тебя в первом варианте сущности предметной области на первом уровне перемешаны с сущностями проекта - например, Donations с Helpers с Settings с References и т. п.Вообще-то у меня тупо разложено по разделам сайта:
А, я думал эти Settings - это Settings проекта в студии.

У меня так (см. ниже слева). А ресурсы - так (см. ниже справа). Но на игровом своём проекте хочу не по сущностям проекта раскидывать - типа Shaders, Textures, Meshes, а по сущностям игры -


Кто что скажет за такую организацию (и за ту, что на картинке, и за ту, что выше)?

st_stПо формату ключей - надписи в основном выводятся во вьюшках, в письмах (автоматических и обычных email-рассылках), очень много в javascript-файлах и т.д., ключи просто делаю уникальными в пределах сайта.
Генеришь какие-нибудь хеши для ключей, чтоли?

Алексей Кcarrotikпропущено...


...на клиенте knockout-VewModels в папочке Models ... Все должно быть на своем месте .. :)Выделяю папки по предметным областям, а не по системным слоям. Мне кажется, что это намного удобнее.
А что, если и члены класса тоже выделять не по сущностям класса как единицы языка (поля, свойства, методы и пр.), а по сущностям класса как сущностям предметной области (поля, свойства, события и т. д., отвечающие за то-то, потом такая же группировка - для того-то и т. д.)?

Ну т. е. не так




а так




Я вижу удобство в том, что если надо исправить что по логике предметной области - то не надо искать все куски, относящиеся к этой сущности. Однако, если надо что-то исправить по сущности кода (например, сделать кучу свойств приватными или сменить тип данных), то такая организация членов класса плохая.

НО! Для быстрого исправления по сущностям кода у нас есть рефакторинг, а рефакторинга для быстрого исправления по сущностям предметной области у нас нет.

А если надо перечисление, класс или структуру объявить, которые именно к данной сущности предметной области относятся, то в подходе "всё по сущностям предметной области" все эти объявления идут как раз под регион этой самой сущности предметной области. А в подходе "всё по сущностям языка" они идут в какой-нибудь отдельный факл Enums и отдельный файл с классом... ну или максимум что предусмотрено - запихать эти перечисление и класс прямо куда-нибудь в класс сущности предметной области.

skyANAP.S.: тачка не умеет свой общий вес считать, не её ответсвенность :)
Это только пример был.

Проблема в том, что в той или иной ситуации для меня удобно так или этак. А что, если иногда надо и так, и этак? Нет ли какой другой организации кода, чтобы и для удобного редактирования по сущностям языка программирования, и для удобного редактирования по сущностям предметной области было?

А вообще предполагается, что модели в ASP.NET MVC и в WPF'овском MVVM как бы одни и те же? Т. е. главная идея-то, как я думал, это что можно под одну и ту же модель сделать разные модели представления - для разных движков рендеринга. Вот тогда будет вся мощь. А если у вас только сайт или только десктопное приложение, и больше логику этой предметной области не предполагается нигде использовать, то, конечно, для вас MVC-MVVM - лишнее усложнение.

Понимаете, они там, в МС - небожители, гуру архитектур и вообще Непознаваемые. У них всякие службы, сайты, десктопы, сервисы, системы, вот это всё. Они там уже привыкли, что логику, раз написанную, надо то там, то тут применять. Вот они и создают всё под суровый мегаэнтерпрайз, причём с закосом в софтверный энтерпрайз. Это мы тут, иваны, родства не помнящие, сирые и убогие клепатели форм. Рази ж мы когда-нибудь делали что-то сложнее трёх форм и пехапешного сайта-визитки? Куда нам понять дела таких гигантов, как МС. МС за год может поднять такую штуку, как сильвер или WPF, и через год уже сменить технологию, а мы даже угнаться не можем за ними. - В этом суть.

авторА вообще предполагается, что модели в ASP.NET MVC и в WPF'овском MVVM как бы одни и те же? Т. е. главная идея-то, как я думал, это что можно под одну и ту же модель сделать разные модели представления - для разных движков рендеринга. Вот тогда будет вся мощь.
Но когда глянул, какие навороты в моделях в ASP.NET MVC и в WPF, то понял, что взаимозаменить их будет нелегко. - Слишком уж разная она, логика сайтов и десктопа.

skyANAНемоКэп42Но когда глянул, какие навороты в моделях в ASP.NET MVC и в WPF, то понял, что взаимозаменить их будет нелегко. - Слишком уж разная она, логика сайтов и десктопа."Слишком уж разная" - это сколько процентов? 10, 20?
На модельки в WPF обычно вышается INotifyPropertyChanged, а на... Ой, перепутал с контроллерами. Чёта у меня в голове вертелось, что у тех и у тех разные атрибуты понаставлены - у МВЦшных всякие Authorize, HttpGet/Post и прочее. Но это контроллеры, да...

ИзопропилНемоКэп42, и через год уже сменить технологию, а мы даже угнаться не можем за ними.
это личные трудности. "Мы" не говори.
Кто может угнаться, тот не жалуется на "кинула с сильверлайтом" и "неясность в будущем WPF". Наоборот - он радуется, что каждый год что-то новенькое МС подбрасывает. А то скучно жить ведь. У того, кто всё успевает, уже завтра релизятся всякие приложухи на плитках с изменяющимся интерфейсом в зависимости от форм-фактора устройства, в стиле Continuity.

skyANAНемоКэп42пропущено...

На модельки в WPF обычно вышается INotifyPropertyChanged, а на... Ой, перепутал с контроллерами. Чёта у меня в голове вертелось, что у тех и у тех разные атрибуты понаставлены - у МВЦшных всякие Authorize, HttpGet/Post и прочее. Но это контроллеры, да...Тут надо добавить, что Модель - это не только "модельки", где "в WPF обычно вышается INotifyPropertyChanged".
Если это осознаешь, то поймёшь, что не слишком-то они и разные :)
Даваще!

Я вот раньше всё по букварям делал. Боялся шагу в сторону ступить. Выискивал по всяким стековерфлоувам, чё там скит, смит или липперт какой скажут. А щас я на них плюю! Чёкаво!? Кто на меня?!.. Я щас сам себе хозяин. Могу и так, могу и этак сделать. Один хрен работает. Мне щас всякие портреты не авторитет. Для меня щас один авторитет - Базаров и нигилизм. Бо учит жить не обращая ни на кого внимания, чтобы бошку не засирали. Независимость! Свобода! Вотэтапамне!

skyANAНемоКэп42пропущено...

Даваще!

Я вот раньше всё по букварям делал. Боялся шагу в сторону ступить. Выискивал по всяким стековерфлоувам, чё там скит, смит или липперт какой скажут. А щас я на них плюю! Чёкаво!? Кто на меня?!.. Я щас сам себе хозяин. Могу и так, могу и этак сделать. Один хрен работает. Мне щас всякие портреты не авторитет. Для меня щас один авторитет - Базаров и нигилизм. Бо учит жить не обращая ни на кого внимания, чтобы бошку не засирали. Независимость! Свобода! Вотэтапамне!Ахаха. А я наоборот как-то всё сам. Гради Буча прочитал, т.к. в институте задавали его читать.
А потом оказалось, что я понимаю Модель, как большинстов других разработчиков с прямыми руками :)
Для меня модель - это чисто логика предметной области. Всякие тырфейсы и прочие "нахлобучки" - только которые относятся к языку, а не всякой привнесённой функциональности. Т. е. не всякие Authorize от asp.net, но INotifyPropertyChanged, Required и т. д., которые просто помогают откомпактить и упростить внедрение логики для граничных условий, отслеживания изменений свойств и тому подобное.

При этом я к модели отношу и данные, а не только функциональность. Потому что в реале это всё связано, а в программировании разделено только потому, что так повелось, что функциональность и БД пошли разными путями. Но если применять всякие подходики, типа code first и т. п., то можно и всё на языке программирования функциональности сделать.

А логика в БД - только если больше нихрена не знаешь, кроме своего T-SQL или чего там у тебя в этой СУБД. Потому что элементарно - более скудный язык в этих СУБД, чем нормальный язык программирования типа шарпа или джавы.

Ну, конечно, всё это условно и в идеале. Если скажут на работе, что рисуем жопой чёрный квадрат малевича - да хрен с вами, только баблинский вовремя выкатывайте. По крайней мере, если с деньгами напряг, то можно и потерпеть чутка.