Как бы вроде очевидно, что stateful по возможности лучше не использовать. И правда — когда избавился от stateful — несколько лишнего кода удалил.
Но где об этом сказано? Получается, только из уст в уста — четкого свода правил вроде как нет.
Так же вопрос про свойство с типом IAsyncEnumerable вызвал разногласия, но потом вроде как сошлись, что лучше так не делать. Но тогда тот же вопрос со свойствами IEnumerable — когда и где они уместны и уместны ли?
Так же выбор правильных nuget-пакетов. Ведь из каких кирпичей строишь дом — тоже немаловажно.
Ну и множество таких практических вопросов, которые вроде бы и элементарные, но готовых ответов нигде не встречал.
S>Как бы вроде очевидно, что stateful по возможности лучше не использовать.
Куда же без состояния? другое дело что сохраняя его в БД упрощаешь прикладной код своего приложения.
S>Так же выбор правильных nuget-пакетов. Ведь из каких кирпичей строишь дом — тоже немаловажно.
Лучше из подводных камней. S>Что можете порекомендовать?
Костыль по необходимости.
Здравствуйте, vitz, Вы писали:
V>Здравствуйте, Shmj, Вы писали:
S>>Что можете порекомендовать?
V>Dependency Injection in .NET
фри https://smarly.net/dependency-injection-in-net
неплохая книжка,
но если честно меня смущает, что автор уже несколько лет ходит по конференциям с микро-примером бронирования мест в самолете
и убеждает всех избавляться от зависимостей.
Здравствуйте, Shmj, Вы писали:
S>Что можете порекомендовать?
Перестать задавать глупые вопросы? Это ведь даже не "вопросы начинающего", а какая-то ахинея. По аналогии: "Ребят, какие формулы мне использовать в математике? Вот синус знаю, котангенс...". И чего ты хочешь от этого тупого вопроса? Есть "общие соображения" по классу задач, может даже 50% общего кода, но "одна архитектура на всё" — не существует. Займись реальными задачами, а не пускай в воздух свои глупые теоретизирования.
Правильной архитектуры не существует.
Архитектура зависит от решаемых задач.
Пример: компиляторы, IDE, операционные системы, корпоративные системы, настольные системы, облачные системы.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Книга по правильной архитектуре .Net проектов
Здравствуйте, LaptevVV, Вы писали:
LVV>Пример: компиляторы, IDE, операционные системы, корпоративные системы, настольные системы, облачные системы.
На .Net из всего перечисленного можно писать только корпоративные системы и, смотря что подразумеваете, облачные системы (не гипервизоры а то что на них крутится). Так что вопрос корректен.
Ни операционные системы ни IDE ни компиляторы нет смысла писать на .Net по очевидным причинам. Т.е. шутки ради можно, конечно, но не более того.
Re[3]: Книга по правильной архитектуре .Net проектов
Ну да, но все это выглядит как продажа пылесоса.
Из той же серии что и Роберт Мартин. Тот тоже носится уже 20 лет с приложением для фитнеса доказывая свое превосходство над простыми смертными.
Ничего не имею против но я несколько раз перечитывал статью но так и не понял преимущества такого подхода. Да еще как средство верификации дублирование на хаскеле.
Больше понравилась вот эта статейка про фп в архитектуре https://github.com/louthy/language-ext/wiki/Thinking-Functionally:-Application-Architecture
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[3]: Книга по правильной архитектуре .Net проектов
Здравствуйте, Shmj, Вы писали:
S>Ни операционные системы ни IDE ни компиляторы нет смысла писать на .Net по очевидным причинам. Т.е. шутки ради можно, конечно, но не более того. Мне даже интересно стало — что, по вашему, мешает написать компилятор на .Net? И на чём бы вы взялись это делать?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Книга по правильной архитектуре .Net проектов
Здравствуйте, Sinclair, Вы писали:
S>>Ни операционные системы ни IDE ни компиляторы нет смысла писать на .Net по очевидным причинам. Т.е. шутки ради можно, конечно, но не более того. S> Мне даже интересно стало — что, по вашему, мешает написать компилятор на .Net? И на чём бы вы взялись это делать?
Присоединюсь к вопросу, но в части IDE.
P.S. Впрочем перечень очевидных причин почему в managed среде (и .Net в частности) тоже было бы интересно увидеть
Re[3]: Книга по правильной архитектуре .Net проектов
LVV>>Пример: компиляторы, IDE, операционные системы, корпоративные системы, настольные системы, облачные системы. S>На .Net из всего перечисленного можно писать только корпоративные системы и, смотря что подразумеваете, облачные системы (не гипервизоры а то что на них крутится). Так что вопрос корректен. S>Ни операционные системы ни IDE ни компиляторы нет смысла писать на .Net по очевидным причинам. Т.е. шутки ради можно, конечно, но не более того.
1. Очевидные причины — в студию!
2. Ну, почему же. Никаких шуток.
Оберон, в котором управление памятью осуществляет система,
вполне подходящий язык и для написания компиляторов, и для написания IDE, и для написания операционных систем. http://people.inf.ethz.ch/wirth/ProjectOberon/index.html
Это вполне себе императивный ОО-язык высокого уровня, который по надежности превосходит (С++ + C# + Java) вместе взятые.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Книга по правильной архитектуре .Net проектов
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, vaa, Вы писали:
vaa>>Ну да, но все это выглядит как продажа пылесоса.
Doc>Почему? Разные парадигмы — разные подходы, согласно этим парадигмам. Вполне логично.
Логично пока ты открыт для доклада, но в докладах существует доля манипуляции.
Нам показывают кусочек кода и доказывают что так намного лучше.
Но ведь избавиться от зависимостей на самом деле нельзя как и от состояния. Как ни крути.
Можно лишь сдвинуть как иногда говорят подальше.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[7]: Книга по правильной архитектуре .Net проектов
Здравствуйте, vaa, Вы писали:
Doc>>Почему? Разные парадигмы — разные подходы, согласно этим парадигмам. Вполне логично. vaa>Логично пока ты открыт для доклада, но в докладах существует доля манипуляции.
И без докладов не вижу ничего странного в "Разные парадигмы — разные подходы". Я понимаю что после ООП тот же подход к реализации DI привычен и его хочется затащить в ФП. Но зачем, если это будет уже начинать напоминать костыль.
Re[2]: Книга по правильной архитектуре .Net проектов
Здравствуйте, LaptevVV, Вы писали:
LVV>Правильной архитектуры не существует. LVV>Архитектура зависит от решаемых задач. LVV>Пример: компиляторы, IDE, операционные системы, корпоративные системы, настольные системы, облачные системы.
Я где-то прочитал, что существует всего пять типов компьютерных программ и сейчас вспомнить не могу, где это прочитал.
1. Операционные системы
2. Службы
3. Серверы
4. Приложения
5. Игры
Их функции:
1. Обслуживают железо и другие программы.
2. Обслуживают ОС и другие программы.
3. Обслуживают другие программы.
4. Обслуживают пользователя, работают с информацией.
5. Обслуживают пользователя, но не работают с информацией — принципиальное отличие от приложений.
S>>Что можете порекомендовать? V>Писать код. Любой более-менее сложный проект сам научит как его правильно структурировать, чтобы он не начал проседать под собственным весом. V>Одна из лучших книг по теме, которые я когда-либо встречал: V>A Philosophy of Software Design by John Ousterhout
Отличнейшая книга. Вы же, собственно, ее мне и советовали полгода/гож назад. Я правда до конца пока не дочитал,
дочитываю. Осталось что-то вроде про комментарии и наименование переменных. Но первые глав 6 просто круть
Совершенно перпендикулярно "Чистому коду" Мартина.
Тут можно с кратким содержанием познакомится -- https://web.stanford.edu/~ouster/cgi-bin/cs190-winter18/lecture.php?topic=modularDesign.
ТС скорее спрашивает не общий подход, а именно для .net -- когда и зачем шина, что от нее требовать в той
или иной ситуации и т.п. Т.е. что-то вроде шаблонов Фаулера выше. Хотя тут чтение блогов и форумов типа design
могут помочь не меньше.
А эта книга вообще для всего, хоть для написания игр.
