Здравствуйте, Baudolino, Вы писали:
IT>>Потому что в последние лет 8 появились более продвинутые способы работы с БД. B>А можно более развернуто? Какие?
Большие дяди в последнее время используют исключительно LINQ.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Qulac, Вы писали:
Q>Зачем вообще тогда нужна архитектура по, разделение интерфейсов и прочее, прочее. Мы ведь про архитектуру говорим или нет?
А зачем нужна архитектура и интерфейсы? Для ответа на этот вопрос есть другой более конкретный вопрос для каждого конкретного случая:
— Какую проблему решает конкретное разделение интерфейсов, конкретное прочее и конкретное другое прочее?
Часто оказывается, что разделение на интерфейсы делается только ради архитектуры и ничего другого. И тогда мы задаём первоначальный вопрос:
— А зачем нужна такая архитектура?
Q>Тогда вообще ни чего не нужно, можно писать как бог на душу положит.
Попробуй. Хорошо писать как бог на душу положит мало у кого получается. Это вывсшее дао программирования. Я пока таких людей не встречал.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, another_coder, Вы писали:
_>В примере с тремя источниками данных, они все предлставляют собой одно и то же: хранилище данных. Для модуля системы, который использует хранилище данных, не важно что именно это (БД, IList, файл или web service).
Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>1)Архитектуры бывают разные и иногда это не просто подключил 10 сторонних библиотек и используешь. S>Если библиотеку писали люди, осилившие FDG — именно что подключается и используется. Посмотри на сам фреймворк — полно отличных примеров и хорошего дизайна, и хорошего, но перенавороченного. А вот примеры из разряда "не делайте так вообще" по пальцам пересчитать можно и в основном это или наследство от fw 1.0 или последствия попытки поиграть в "мы модные и современные" с .Net Core.
Сам фреймворк между прочим и есть базовая библиотека. Там воленс-ноленс сложных решений быть не должно. С архитектурной точки зрения.
S>>2)Библиотеки, за исключением базовых типа io, маршалинга, синх. примитиовов и проч. не из воздуха берутся. S>Да ладно. Публичное API, если его вообще делают целенаправленно, а не постфактум — именно что набор хороших идей с других похожих библиотек + правки по опыту догфудинга. Проблемы в основном возникают, когда решения перетягиваются в лоб с других платформ людьми, которые дотнет знают слабовато. Вот тогда да — обнять и плакать
Не понял куда опять дискуссия зашла Все мало-мальски серьезные приложения используют кучу библиотек в императивном стиле штоле? Типа:
библиотека1.вызов1()
библиотека2.вызов3()
библиотека1.вызов2()
...
Или же идет оркестрации на несколько более абстрактному уровне. Т.е. если исп. стороннюю библиотеку или компонент, то паттерны ни-ни. Судя по дискуссии получается так. Я не вижу проблем использовать паттерны и сторонние компоненты, если речь об этом.
S>>>Желающие поспорить могут посмотреть на популярность Rx, TPL DataFlow или CodeContracts.
S>>Если я правильно понял Ваш посыл, то: S>>2) смысл сравнивать слабый маркетинг и инженерные решения?
S>Не, я именно про удобство использования — все вышеперечисленные требуют держать в голове ментальную модель самой библиотеки (местами крайне нелогичную) и пересказывать свои хотелки в терминах этой модели. Что ставит однозначный крест на сколько-нибудь широком использовании. S>Ради справедливости, Rx сам по себе очень даже неплох, а свежие версии Code Contracts в принципе почти пригодны к использованию в продакшне. Но задел на старте что там, что там был прокакан (пардон мой французский) прям образцово. А проблема всё та же, что сейчас с .Net Core — внезапно™ выяснилось, что идея забить на реальные сценарии использования немножко не работает.
S>>ЗЫ:Вот я это написал, и как водится перечитал сообщения на которое отвечаю -- что в этом списке делает TPL, у него вроде все неплохо? Я точно правильно понял Ваш посыл? S>Не TPL, а TPL Dataflow. У них своя атмосфера
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, another_coder, Вы писали:
_>>В примере с тремя источниками данных, они все предлставляют собой одно и то же: хранилище данных. Для модуля системы, который использует хранилище данных, не важно что именно это (БД, IList, файл или web service).
IT>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?
Здравствуйте, IT, Вы писали:
IT>Большие дяди в последнее время используют исключительно LINQ.
Между нами, большими дядями, LINQ существует только на одной, причем не самой популярной платформе.
Здравствуйте, gandjustas, Вы писали:
G>Вы несущественными не то объявили. G>Несущественные различия это делать Repository или extension-методы для List<T>. Это различие не влияет на характеристики программы. G>А тип источника данных очень сильно влияет.
Начнем с того, что я несущественным ничего не объявлял. Я продемонстрировал, как детали реализации могут быть скрыты в определенных ситуациях, но я не утверждал, что это всегда возможно. Вы понимаете различие между словами "существует" и "всегда"? А их отрицание построить можете и применить к нашему разговору?
G>Отлично — у вас есть веб-сервис, обычный web api с Get и Post по ключу. А вы напроектировани репозиторий с поиском по параметрам. Что дальше делать? G>И стоило его изначально таким делать?
Думаю, стоит начать с того, что это "напроектировали" вы, а не я. Я не натягиваю паттерны на сферических коней.
G>Но писать такое с нуля для одного приложения никто не будет, надо пользоваться готовым. Поэтому паттерн repository категорически не в тему, надо пользоваться orm.
Ваша категоричность пока что голословна.
G>Repository сам по себе велосипед при наличии ORM.
А LINQ это, по-вашему, ORM? И, кстати, сколько разных ORM вы знаете (в смысле использовали)? На каких платформах?
G>Принципиальное различие в скорости работы. Как только вызовы начинают пересекать граници процесса надо внимательно следить как часто происходят обращения и сколько данных передается. Иначе получается тормозное говно. G>И это тоже часть архитектуры. Причем гораздо более важная, чем паттерны.
Термин "преждевременная оптимизация" знаком? Где вы увидели пересечение "границ процесса" при реализации паттерна?
B>>Контракт определяет интерфейс, а не его реализация. G>Ты чего сейчас сказал? G>Контрат шире чем интерфейс. Например интерфейс не может описать сайд-эффекты.
Интерфейс не должен описывать побочные эффекты. С точки зрения пользователя интерфейса побочных эффектов не должно существовать — это аксиома ООП, которую самое время выучить.
G>Для ORMов контракт обычно такой — ты работает с коллекцией объектов в памяти, а потом вызываешь функцию сохранения изменений в БД. В интерфейсе сохранение никак не фигурирует.
Функция сохранения изменений в БД — часть интерфейса.
G>И ты можешь ошибочно подумать, что таблица в базе эквивалентна List<T>, хотя это совсем не так.
Вы всё время делаете какие-то очень странные и ничем не обоснованные суждения насчёт того, как я думаю, и выдаёте необоснованные отрицания достойные включения в "Женскую логику" Беклемишева в качестве примера отвергнутых аргументов. Предложение: вместо того, чтобы использовать фразы типа "это совсем не так", вы будете с этого момента для продолжения дискуссии аргументировать, почему не так, в каких обстоятельствах?
G>>>Само по себе добавление репозитория на ранних этапах — бесполезное усложнение кода. Можно банально обращаться к статическим спискам в памяти пока не появится необходимость сохранять данные. B>>У вас десять классов, работающих с хранилищем объектов типа А. Что проще — поменять в одном месте реализацию интерфейса хранилища объектов, или поменять во всех местах работу с ним со списка на что-то иное? G>Кто тебе сказал про десятки классов?
Допустим, у вас примерно десять классов... Рядовая ситуация на крупном проекте.
Здравствуйте, Baudolino, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Вы несущественными не то объявили. G>>Несущественные различия это делать Repository или extension-методы для List<T>. Это различие не влияет на характеристики программы. G>>А тип источника данных очень сильно влияет. B>Начнем с того, что я несущественным ничего не объявлял. Я продемонстрировал, как детали реализации могут быть скрыты в определенных ситуациях, но я не утверждал, что это всегда возможно. Вы понимаете различие между словами "существует" и "всегда"? А их отрицание построить можете и применить к нашему разговору?
Что сказать-то хотел?
G>>Отлично — у вас есть веб-сервис, обычный web api с Get и Post по ключу. А вы напроектировани репозиторий с поиском по параметрам. Что дальше делать? G>>И стоило его изначально таким делать? B>Думаю, стоит начать с того, что это "напроектировали" вы, а не я. Я не натягиваю паттерны на сферических коней.
То есть вам таки важно какой источник данных? Тогда зачем repository?
G>>Но писать такое с нуля для одного приложения никто не будет, надо пользоваться готовым. Поэтому паттерн repository категорически не в тему, надо пользоваться orm. B>Ваша категоричность пока что голословна.
То есть объективных причин использовать repository нет?
G>>Repository сам по себе велосипед при наличии ORM. B>А LINQ это, по-вашему, ORM?
По нашему linq это query object, а ORM это linq-провайдер, он же repository в определении Фаулера.
B>И, кстати, сколько разных ORM вы знаете (в смысле использовали)? На каких платформах?
Использовал EF, Linq2DB, Nhibernate, linq2sql на C#, FSharp.Data, Hibernate на java, а также писал свои ORM на Delphi, C# и C++.
G>>Принципиальное различие в скорости работы. Как только вызовы начинают пересекать граници процесса надо внимательно следить как часто происходят обращения и сколько данных передается. Иначе получается тормозное говно. G>>И это тоже часть архитектуры. Причем гораздо более важная, чем паттерны. B>Термин "преждевременная оптимизация" знаком? Где вы увидели пересечение "границ процесса" при реализации паттерна?
Мне знаком термин преждевременная пессимизация. Когда в угоду паттернам код пишется на порядок более медленным, чем он мог бы быть.
Пересечение границ процесса случается чуть менее чем в каждом случае, кроме хранилища в памяти. А каждый второй писать repository проектирует его, как будто это просто коллекция в памяти. Вот и получается пессимизация, которую уже крайне сложно поправить.
B>>>Контракт определяет интерфейс, а не его реализация. G>>Ты чего сейчас сказал? G>>Контрат шире чем интерфейс. Например интерфейс не может описать сайд-эффекты. B>Интерфейс не должен описывать побочные эффекты. С точки зрения пользователя интерфейса побочных эффектов не должно существовать — это аксиома ООП, которую самое время выучить.
Дай ссылку на того, кто эту аксиому доказал. Мне кажется ты ООП с ФП путаешь и то неверно понимаешь побочные эффекты в ФП.
Алан Кей и Бертран Мейер как раз в своих определениях ООП опираются на побочные эффекты при взаимодействии с объектами.
G>>Для ORMов контракт обычно такой — ты работает с коллекцией объектов в памяти, а потом вызываешь функцию сохранения изменений в БД. В интерфейсе сохранение никак не фигурирует. B>Функция сохранения изменений в БД — часть интерфейса.
Точно? А если у нас таки коллекция в памяти? Или веб-сервис?
G>>И ты можешь ошибочно подумать, что таблица в базе эквивалентна List<T>, хотя это совсем не так. B>Вы всё время делаете какие-то очень странные и ничем не обоснованные суждения насчёт того, как я думаю, и выдаёте необоснованные отрицания достойные включения в "Женскую логику" Беклемишева в качестве примера отвергнутых аргументов. Предложение: вместо того, чтобы использовать фразы типа "это совсем не так", вы будете с этого момента для продолжения дискуссии аргументировать, почему не так, в каких обстоятельствах?
Мне приходится озвучивать твои мысли, потому что ты их не озвучиваешь и общаешься полунамеками. Я уже перестал понимать какую позицию ты пытаешься отстоять.
G>>>>Само по себе добавление репозитория на ранних этапах — бесполезное усложнение кода. Можно банально обращаться к статическим спискам в памяти пока не появится необходимость сохранять данные. B>>>У вас десять классов, работающих с хранилищем объектов типа А. Что проще — поменять в одном месте реализацию интерфейса хранилища объектов, или поменять во всех местах работу с ним со списка на что-то иное? G>>Кто тебе сказал про десятки классов? B>Допустим, у вас примерно десять классов... Рядовая ситуация на крупном проекте.
И что? Какую задачу мы решаем?
Здравствуйте, another_coder, Вы писали:
IT>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)? _>Парочка найдется.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, another_coder, Вы писали:
IT>>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)? _>>Парочка найдется.
G>Расскажи про них.
После вас. Только не забудьте привести архитектуру с коментами почему именно такое решение было принято. Более не вижу смысла продолжать этот тред, т.к. оффтоп.
Здравствуйте, another_coder, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, another_coder, Вы писали:
IT>>>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)? _>>>Парочка найдется. G>>Расскажи про них. _>После вас. Только не забудьте привести архитектуру с коментами почему именно такое решение было принято. Более не вижу смысла продолжать этот тред, т.к. оффтоп.
Да вот у меня как-то не было примеров, чтобы одна и та же программа могла работать с любым источником данных. Скорее обратное. Даже небольшие различия в разных движках БД приводили к различному коду, даже с применением ORM.
Здравствуйте, another_coder, Вы писали:
IT>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)? _>Парочка найдется.
А оно там реально было нужно или всё ради понтов?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Baudolino, Вы писали:
IT>>Большие дяди в последнее время используют исключительно LINQ. B>Между нами, большими дядями, LINQ существует только на одной, причем не самой популярной платформе.
Нам, большим дядям пофиг.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, another_coder, Вы писали:
_>>Здравствуйте, gandjustas, Вы писали:
G>>>По-разному это как? Приведи пример.
_>>Ну например, 1 выбирает по одному флагу, 2й выбирает по двум. Система мультитенант, и логика работы определяется динамически. Хранилище у всех IList. G>Сделать две функции не?
Так можно. Речь тут не о выборе оптимального решения, а о взгляде на роль ропозитория. Не оффтопьте, плиз.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, another_coder, Вы писали:
IT>>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)? _>>Парочка найдется.
IT>А оно там реально было нужно или всё ради понтов?
Было сделано по необходимости. Смысла отвечать глубже нет. Если интересно заведите отдельную тему.
Здравствуйте, another_coder, Вы писали:
_>>>Ну например, 1 выбирает по одному флагу, 2й выбирает по двум. Система мультитенант, и логика работы определяется динамически. Хранилище у всех IList. G>>Сделать две функции не? _>Так можно. Речь тут не о выборе оптимального решения, а о взгляде на роль ропозитория. Не оффтопьте, плиз.
Не просто о роли, а о том осмысленно ли его использовать. Ты предлагаешь лепить некоторый паттерн, там где достаточно двух фукнций.
В этом случае паттерн должен обладать явными преимуществами. Расскажи о них.
Если нам не помогут, то мы тоже никого не пощадим.
Все мало-мальски серьезные приложения используют кучу библиотек в императивном стиле штоле? Типа:
