Подумал по поводу флага LazyLoad — в принципе можно динамически генерировать маппинг на основе декларативных указаний где нужен LazyLoad, а где нет, но тогда маппинг станет сложнее и велик риск неправильно указать необходимость LazyLoad, и если ошибиться, то потом будет сложно разобраться, почему программа тормозит.
Если же для извлечения данных использовать джойны только по нужным таблицам, то не ошибёшься, но писанины станет чуть больше. Я предпочитаю решения, в которых сложнее ошибиться. Подход с идентификаторами можно совместить с ссылками на связанные сущности (NavigationProperty). Тогда можно обеспечить хорошее быстродействие там, где это нужно, и удобство использования в остальных местах.
В любом случае, не вижу серьёзного нарушения дизайна в добавлении поля с идентификатором. В конце концов, можно просто этим полем не пользоваться, и добавить юнит-тест, проверяющий что нигде в вашем коде это поле не используется.
(Часть комментария не сохранилась, видимо из-за наличия в нём <ob_ject> без подчёркивания)
<ob_ject>, а в Dictionary<int, ob_ject> (под хранилищем-словарём имеется ввиду бд).
3)
Customer customer = CreateCustomer(dto);
session.Save(customer);
ids.Add(customer.Id);
Если вы используете для этой задачи Entity Framework, то он будет вставлять записи в БД по мере сохранения их в сессии для того, чтобы получить Id, т.к. единственная доступная стратегия генерации целочисленных идентификаторов в EF — database identity.
А вот и неправда. Пока не будет вызвано session.SaveChanges(), ничего в базу данных сохраняться не будет, а будут подставлены фиктивные идентификаторы. Поэтому собирать идентификаторы смысла нет, вместо этого нужно использовать ссылки на связанные сущности (NavigationProperty).
4)
Работа с закешированными объектами
public Order(Customer customer, OrdersContext context)
{
context.Entry(customer).State = EntityState.Unchanged;
Customer = customer;
}
… устанавливает зависимость между доменной и инфраструктурной логикой
А что мешает, вынести context.Entry(customer).State = EntityState.Unchanged в класс, который занимается кэшированием?
Передача OrdersContext в метод доменного объекта нарушает принцип разделения ответственности, т.к. класс Order в этом случае содержит информацию о том, как он сохраняется в базе.
public virtual void RemoveLine(OrderLine line, OrdersContext db)
{
Lines.Remove(line);
db.OrderLines.Remove(line);
}
Если бы вместо OrdersContext был интерефейс IOrdersContext, то Order не знал бы КАК он сохраняется в бд, а просто знал бы, ЧТО он сохраняется в неком хранилище. И это было бы гораздо лучше, чем гибернейтовская автомагия.
2)
— Entity Framework побуждает разработчиков использовать идентификаторы. Частично из-за того, что это дефолтный способ для того, чтобы ссылаться на связанные сущности, частично из-за того, что все примеры в документации используют именно этот подход. В NHibernate, напротив, дефолтный способ объявления ссылки на связанную сущность — это ссылка на объект этой сущности
В гибернейте есть специальных флаг отложенной загрузки связанных сущностей LazyLoad. Беда в том, что необходимость отложенности загрузки зависит от места использования. В итоге для сущностей, которые используются в нескольких местах, или куча ненужной информации из бд тянется (если не установлен LazyLoad), или из-за отложенной загрузки для каждого бизнес объекта из выборки (коих может быть миллион) по несколько запросов в бд идёт (т.е. несколько миллионов запросов) (это если установлен LazyLoad), или в коде несколько одинаковых маппингов, отличающихся лишь флагами LazyLoad. То есть или получается нарушение DRY, или всё жутко тормозит. Подход с идентификаторами мне кажется более приемлемым. Невелика беда, что данные хранятся не в хранилище List
Имхо, человек может отказываться от признания собственных ошибок не только из-за боязни потратить часть накопленного им авторитета, но и потому что если он признает ошибочность какого-либо его фундаментального убеждения, то ему придётся пересматривать и довольно значительную часть других своих убеждений.
По поводу шакалов, о которых вы говорили — тут мне хочется рассказать вам историю.
1)Однажды в школе детям задали написать сочинение на тему «Кем я хочу стать в будущем». Дети написали «Я хочу стать бухгалтером», «Я хочу стать управленцем» и тому подобное. А один мальчик написал «Я хочу стать счастливым человеком». Учительница сказала: «Ты не понял тему сочинения». «Нет, это вы не поняли жизнь», — ответил он.
Я не о том, что накопление авторитета ведёт к несчастливости. Я о том, что процесс должен доставлять хоть какое то удовлетворение. Одно лишь обладание вещью не делает счастливее, как бы жаден не был её обладатель, если эта вещь не нужна его обладателю.
К цели могут привести много путей.
Необязательно не признавать свои ошибки из-за страха потерять статус всезнающего. Никто не всезнающ. Необязательно считать наглецами тех, кто указывает на ошибочность мнения — они поступают так, как считают правильным. Если вы не будете глухи к чужому мнению, это может лишь укрепить ваш авторитет толкового лидера.
Но это, конечно, субъективное мнение.
Также люди склонны верить авторитетам («учёными доказано, что ...», «известный доктор НиктоОНёмНикогдаНеСлышал с уверенностью заявляет, что ...»), и считают более длинные тексты более убедительными, даже если 80% текста — вода.
Природой заложено, что человек экономит на мыслительных процессах, т.к. это затратно. Ну а вообще, чем больше человек заинтересован в правильности решения, тем больше он вложит сил в обдумывание проблемы. С этого и надо начинать — не тратить свою жизнь на неважные проблемы или грамотно мотивировать тех, на кого сваливаешь свои проблемы. В противном случае, люди при любом раскладе будут принимать решения необдуманно.
Имхо, в статье мало конкретики, только ничем не подкрепленные фразы типа «ударит по малому бизнесу», «иностранные предприниматели перестанут открывать бизнес в РФ». Сомнительно, что аренда\постройка ЦОДов в России обойдётся гораздо дороже, чем зарубежом. И да, откуда такие цифры — непонятно.
Если добавить к этому тот факт, что вы не даёте возможности воспользоваться, как вы утверждаете, уже реализованной вами системой
Приношу извинения, авторы в личке дали ссылку на сервис. Сервис и правда довольно интересный: вместо ссылок на сайты он сразу извлекает краткую информацию из сайта, причём информация и вправду часто отвечает на задаваемый вопрос.
Но я всё ещё сомневаюсь, что сервис и вправду работает по тому принципу, который описывали авторы. Вполне может быть, что рассчитывается количество совместных использований слов + стемминг.
Например: «Честно признаюсь, я сама когда-то давно очень любила всякие стрелялки, при этом я не замечала за собой агрессии.» «Стрелялки» часто употребляется с «компьютерные игры», «агрессия» с «жестокостью», следовательно это предложение хороший кандидат на нечто имеющее отношение к «жестокость компьютерных игр». К тому же, «стрелялки» и «агрессия» вообще часто употребляются в статьях про «жестокость компьютерных игр», поэтому это предложение хороший кандидат на то, чтобы иметь отношение к обсуждению в статье.
В любом случае, задумка оригинальная, сервис довольно интересный (Ещё не протестировал все его возможности).
Удачи вам, ребята!
Современные самообучающиеся системы обучаются отвечать на один вопрос. Например, система распознавания чисел на изображении работает так: сначала одна обученная система отвечает на вопрос «есть ли на изображении единица», потом другая отвечает на вопрос «есть ли на изображении двойка», и так далее. И для их обучения требуется множество изображений, о которых системе известно, есть ли на них заданное число или нет. Нет никаких сложностей для системы самообучиться отвечать, соответствует ли фраза единственному конкретному поисковому запросу, но создать систему, способную отвечать на соответствие ЛЮБОМУ поисковому запросу посредством самообучения — имхо, всё равно, что эмулировать абстрактное мышление (вы бы не смогли создать отдельную обучающую выборку для ответа на каждый конкретный возможный вопрос, ведь количество вопросов очень велико)(напомню, что ваша система, как вы говорите, находит соответствие между «Влияние жестоких компьютерных игр на детей» и «При этом повышенная активность и агрессивность подростка по отношению к окружающему миру она дает ему опору для преодоления собственного страха.»).
При этом абстрактное мышление не имеет ничего общего с самообучением. Абстрактное мышление подразумевает лишь перебор известных «абстрактных» фактов и генерацию из них новых фактов посредством создания цепочек «если — то». И современные компьютерные системы это умеют (почитайте вот эту мою статью на эту тему). Таким образом, для реализации абстрактного мышления не требуется самообучения, а требуется лишь большая база фактов. Самообучение же есть всего лишь способ нахождения неизвестного алгоритма по выведению факта из других фактов при неизвестных логических связях между исходными фактами (например, система может самообучаться по списку кто кому тётя или двоюродная сестра определять кто чья мать, не зная смысла понятий тётя, мама и сестра).
Но вы говорите что реализовали ваш алгоритм благодаря самообучению. А именно следующее:
Обучение не возможно без обратной связи. Обратная связь в модели v 2.3 осуществляется следующим образом – пользователь может скорректировать «точку начала рассуждения» и выбрать направление формирования ответа(размышления) в рамках сформированного инфополя.
Обратная связь всего-лишь отвечает на вопрос, угадала система правильный ответ или же нет, а в вашем случае обратная связь это нечто совсем иное. В попытке поведать, что это такое в вашем случае, вы используете термины, придуманные вами («инфополе», «точка начала рассуждения»). Это не общепринятые понятия (общепринятое значение «инфополя» — это «общее энергоинформационное поле земли, содержащее информацию, прошедшую через мысли живших ранее и ныне живущих людей»). И вы нигде в статье не расшифровываете значения этих понятий, придуманных вами. Если добавить к этому тот факт, что вы не даёте возможности воспользоваться, как вы утверждаете, уже реализованной вами системой, то у меня есть объективные причины сомневаться, что это статья не является очередным фейком.
Resharper тоже так умеет. Не думаю, что граф проектов может быть полезен, чтобы
начать разбираться в большом проекте.
Хотя в других редких случаях может быть полезен: например, если нужно убедиться, что в приложении на основе трехзвенной архитектуры в папке клиента не окажется dll-файлов с sql-ными текстами запросов.
Я вас просил назвать причину, по которой ORM в некоторых случаях не сможет сгенерировать оптимальный sql-запрос, а вы вместо этого начали мне в сто-пятьсотый раз доказывать, что есть различие в концепциях реляционной БД и ООП, даже ссылку скинули. Я много раз повторял: «Я не спорю, концепции реляционного SQL и объектной модели разные, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком?», а вы опять включили свою заезженную пластинку. Из этого делаю вывод, что вы либо избирательно не читаете то что я пишу, либо докопаться до истины для вас не главное. В любом случае не вижу никакого смысла убеждать вас далее.
ваш автоматический объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами
Почему никогда не сможет? Это ваше утверждение хоть как-то связано с тем, что вы до этого написали? Или вы это просто так утверждаете, «без связки»? Если всё-таки связано и по-вашему не сможет, потому что концепции разные, то я отвечу, что программа, написанная на языке концепции логической парадигмы, совершенно спокойно может быть транслирована в программу в процедурной парадигме. Хотя в процедурной парадигме и есть понятия, отсутствующие в логической: например, понятия переменных и функций. Почему из логической в процедурную легко, а из объектно-ориентированной в реляционную ну никак? Запрос к бд, написанный на ООП языке, неплохо транслируется в реляционный SQL. Да, есть некоторые ограничения: нужно использовать методы Where(), Select() и прочее. Да, SQL запрос не всегда получается оптимальным. Но почему он не оптимален? Индекса например не хватает. Давайте научим ORM создавать индексы. Или не оптимален, потому что ORM не поддерживает иерархические запросы. Давайте её и этому научим. Назовите хотя бы одну принципиально нерешаемую проблему, которая мешает ORM всегда эффективно работать со множествами. Или опишите пожалуйста одним предложением причину, почему «объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами», (например, «не сможет, потому что сову на глобус натянуть невозможно») но только чтобы между причиной и следствием была логическая связь.
Если бы ORM решала все проблемы, то абстрагирование от сервера БД было бы полным и вас бы не беспокоили особенности генерации SQL-запросов.
Согласен с тем, что если абстрагирование от сервера БД было бы полным, то не беспокоили бы особенности генерации SQL-запросов. Не согласен с тем, что полное абстрагирование от реляционной БД — единственно возможное решение проблемы необходимости отслеживания получившихся SQL-запросов.
Вы говорите нечто похожее на «трава зелёная, потому что африканские дети голодают». В том что африканские дети голодают, сомнений нет, но при чём тут трава? В том, что концепции реляционного SQL и объектной модели разные, сомнений нет, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком?
Я не зря указал, что именно рядовому программисту не будет необходимости знать подробности её реализации.
Разумеется, разработчики файловой системы знают подробности реализации файловой системы. Те, кто делает утилиты для восстановления файлов при сбое файловой системы или диска, знают подробности реализации файловой системы. Но всем кто использует ФС нет необходимости знать детали её реализации. Я не спорю, знать всё на свете — это хорошо (хотя и неосуществимо), и если разработчики, когда их программа даёт сбой по вине аппаратной части, при помощи паяльника всё чинят, это круто. И заодно все баги в операционной системе и драйверах штопают, чтобы «бизнес не оказался в прямой зависимости от чужого кода». Однако речь не о том, насколько хорошо знать подробности реализации инструмента, а о том, насколько хорош инструмент, для использования которого не нужно знать деталей его реализации.
Если же для извлечения данных использовать джойны только по нужным таблицам, то не ошибёшься, но писанины станет чуть больше. Я предпочитаю решения, в которых сложнее ошибиться. Подход с идентификаторами можно совместить с ссылками на связанные сущности (NavigationProperty). Тогда можно обеспечить хорошее быстродействие там, где это нужно, и удобство использования в остальных местах.
В любом случае, не вижу серьёзного нарушения дизайна в добавлении поля с идентификатором. В конце концов, можно просто этим полем не пользоваться, и добавить юнит-тест, проверяющий что нигде в вашем коде это поле не используется.
<ob_ject>, а в Dictionary<int, ob_ject> (под хранилищем-словарём имеется ввиду бд).
3)
А вот и неправда. Пока не будет вызвано session.SaveChanges(), ничего в базу данных сохраняться не будет, а будут подставлены фиктивные идентификаторы. Поэтому собирать идентификаторы смысла нет, вместо этого нужно использовать ссылки на связанные сущности (NavigationProperty).
4)
А что мешает, вынести context.Entry(customer).State = EntityState.Unchanged в класс, который занимается кэшированием?
Если бы вместо OrdersContext был интерефейс IOrdersContext, то Order не знал бы КАК он сохраняется в бд, а просто знал бы, ЧТО он сохраняется в неком хранилище. И это было бы гораздо лучше, чем гибернейтовская автомагия.
2)
В гибернейте есть специальных флаг отложенной загрузки связанных сущностей LazyLoad. Беда в том, что необходимость отложенности загрузки зависит от места использования. В итоге для сущностей, которые используются в нескольких местах, или куча ненужной информации из бд тянется (если не установлен LazyLoad), или из-за отложенной загрузки для каждого бизнес объекта из выборки (коих может быть миллион) по несколько запросов в бд идёт (т.е. несколько миллионов запросов) (это если установлен LazyLoad), или в коде несколько одинаковых маппингов, отличающихся лишь флагами LazyLoad. То есть или получается нарушение DRY, или всё жутко тормозит. Подход с идентификаторами мне кажется более приемлемым. Невелика беда, что данные хранятся не в хранилище List
По поводу шакалов, о которых вы говорили — тут мне хочется рассказать вам историю.
1)Однажды в школе детям задали написать сочинение на тему «Кем я хочу стать в будущем». Дети написали «Я хочу стать бухгалтером», «Я хочу стать управленцем» и тому подобное. А один мальчик написал «Я хочу стать счастливым человеком». Учительница сказала: «Ты не понял тему сочинения». «Нет, это вы не поняли жизнь», — ответил он.
Я не о том, что накопление авторитета ведёт к несчастливости. Я о том, что процесс должен доставлять хоть какое то удовлетворение. Одно лишь обладание вещью не делает счастливее, как бы жаден не был её обладатель, если эта вещь не нужна его обладателю.
К цели могут привести много путей.
Необязательно не признавать свои ошибки из-за страха потерять статус всезнающего. Никто не всезнающ. Необязательно считать наглецами тех, кто указывает на ошибочность мнения — они поступают так, как считают правильным. Если вы не будете глухи к чужому мнению, это может лишь укрепить ваш авторитет толкового лидера.
Но это, конечно, субъективное мнение.
Природой заложено, что человек экономит на мыслительных процессах, т.к. это затратно. Ну а вообще, чем больше человек заинтересован в правильности решения, тем больше он вложит сил в обдумывание проблемы. С этого и надо начинать — не тратить свою жизнь на неважные проблемы или грамотно мотивировать тех, на кого сваливаешь свои проблемы. В противном случае, люди при любом раскладе будут принимать решения необдуманно.
Не совсем понимаю — потеряет доход или вложения иностранных инвесторов?
Приношу извинения, авторы в личке дали ссылку на сервис. Сервис и правда довольно интересный: вместо ссылок на сайты он сразу извлекает краткую информацию из сайта, причём информация и вправду часто отвечает на задаваемый вопрос.
Но я всё ещё сомневаюсь, что сервис и вправду работает по тому принципу, который описывали авторы. Вполне может быть, что рассчитывается количество совместных использований слов + стемминг.
Например: «Честно признаюсь, я сама когда-то давно очень любила всякие стрелялки, при этом я не замечала за собой агрессии.» «Стрелялки» часто употребляется с «компьютерные игры», «агрессия» с «жестокостью», следовательно это предложение хороший кандидат на нечто имеющее отношение к «жестокость компьютерных игр». К тому же, «стрелялки» и «агрессия» вообще часто употребляются в статьях про «жестокость компьютерных игр», поэтому это предложение хороший кандидат на то, чтобы иметь отношение к обсуждению в статье.
В любом случае, задумка оригинальная, сервис довольно интересный (Ещё не протестировал все его возможности).
Удачи вам, ребята!
А можно ссылочку пожалуйста?
При этом абстрактное мышление не имеет ничего общего с самообучением. Абстрактное мышление подразумевает лишь перебор известных «абстрактных» фактов и генерацию из них новых фактов посредством создания цепочек «если — то». И современные компьютерные системы это умеют (почитайте вот эту мою статью на эту тему). Таким образом, для реализации абстрактного мышления не требуется самообучения, а требуется лишь большая база фактов. Самообучение же есть всего лишь способ нахождения неизвестного алгоритма по выведению факта из других фактов при неизвестных логических связях между исходными фактами (например, система может самообучаться по списку кто кому тётя или двоюродная сестра определять кто чья мать, не зная смысла понятий тётя, мама и сестра).
Но вы говорите что реализовали ваш алгоритм благодаря самообучению. А именно следующее:
Обратная связь всего-лишь отвечает на вопрос, угадала система правильный ответ или же нет, а в вашем случае обратная связь это нечто совсем иное. В попытке поведать, что это такое в вашем случае, вы используете термины, придуманные вами («инфополе», «точка начала рассуждения»). Это не общепринятые понятия (общепринятое значение «инфополя» — это «общее энергоинформационное поле земли, содержащее информацию, прошедшую через мысли живших ранее и ныне живущих людей»). И вы нигде в статье не расшифровываете значения этих понятий, придуманных вами. Если добавить к этому тот факт, что вы не даёте возможности воспользоваться, как вы утверждаете, уже реализованной вами системой, то у меня есть объективные причины сомневаться, что это статья не является очередным фейком.
Интересно, а это вы на основании чего решили? Я тоже читал статью, но не увидел, чтобы автор говорил о чём-то подобном.
Почему никогда не сможет? Это ваше утверждение хоть как-то связано с тем, что вы до этого написали? Или вы это просто так утверждаете, «без связки»? Если всё-таки связано и по-вашему не сможет, потому что концепции разные, то я отвечу, что программа, написанная на языке концепции логической парадигмы, совершенно спокойно может быть транслирована в программу в процедурной парадигме. Хотя в процедурной парадигме и есть понятия, отсутствующие в логической: например, понятия переменных и функций. Почему из логической в процедурную легко, а из объектно-ориентированной в реляционную ну никак? Запрос к бд, написанный на ООП языке, неплохо транслируется в реляционный SQL. Да, есть некоторые ограничения: нужно использовать методы Where(), Select() и прочее. Да, SQL запрос не всегда получается оптимальным. Но почему он не оптимален? Индекса например не хватает. Давайте научим ORM создавать индексы. Или не оптимален, потому что ORM не поддерживает иерархические запросы. Давайте её и этому научим. Назовите хотя бы одну принципиально нерешаемую проблему, которая мешает ORM всегда эффективно работать со множествами. Или опишите пожалуйста одним предложением причину, почему «объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами», (например, «не сможет, потому что сову на глобус натянуть невозможно») но только чтобы между причиной и следствием была логическая связь.
Согласен с тем, что если абстрагирование от сервера БД было бы полным, то не беспокоили бы особенности генерации SQL-запросов. Не согласен с тем, что полное абстрагирование от реляционной БД — единственно возможное решение проблемы необходимости отслеживания получившихся SQL-запросов.
Вы говорите нечто похожее на «трава зелёная, потому что африканские дети голодают». В том что африканские дети голодают, сомнений нет, но при чём тут трава? В том, что концепции реляционного SQL и объектной модели разные, сомнений нет, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком?
Я не зря указал, что именно рядовому программисту не будет необходимости знать подробности её реализации.
Разумеется, разработчики файловой системы знают подробности реализации файловой системы. Те, кто делает утилиты для восстановления файлов при сбое файловой системы или диска, знают подробности реализации файловой системы. Но всем кто использует ФС нет необходимости знать детали её реализации. Я не спорю, знать всё на свете — это хорошо (хотя и неосуществимо), и если разработчики, когда их программа даёт сбой по вине аппаратной части, при помощи паяльника всё чинят, это круто. И заодно все баги в операционной системе и драйверах штопают, чтобы «бизнес не оказался в прямой зависимости от чужого кода». Однако речь не о том, насколько хорошо знать подробности реализации инструмента, а о том, насколько хорош инструмент, для использования которого не нужно знать деталей его реализации.