Здравствуйте, gandjustas, Вы писали:
G>Сам факт обработки некоторой выборки уже относится к BL, для DAL достаточно вернуть выборку в удобном для обработки виде.
Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет. Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы. Поэтому GetById, если ничего не найдено, выкидывает исключение. Про orphan records слышал?
G>>>Хоть убей не пойму зачем тому же IQueryable учитывать возможность рефакторинга БД. A>>IQueryable не надо, надо методике доступа к БД, которая включает в себя Linq. G>Linq = IEnumerable\IQueryable + extension methods + anonimous types + object initializers + sql-подобный синтаксис. G>Для полноценной работы с данными не хватает только DML — insert\update\delete. G>Зачем этому всему учитывать возможность рефакторинга БД?
А зачем вообще учитывать возможность рефакторинга, вне контекста Linq?
Здравствуйте, Tom, Вы писали:
G>>Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код. Tom>Обьясните почему? Почему в C# ты от if не отказываешься а в TSQL решаешь отказаться? Просто что бы уменьшить обьём кода в функции?
Поддержка и развитие кода на T-SQL дороже. Вынеся логику в C#, съэкономишь в будущем много времени.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Рама, забудь свои знания С. Они тут тебе не помогут. VD>>"Запись", о которой я говорил — это тип данных, а не понятие из РСУБД (где, впрочем они рассматриваются так же, прост ты не привык). Запись есть набор разнотипных именованных значений. Скажем в C# 3.0 ей аналогичны анонимные типы. Не полностью аналогичны, правда... с ограничениями... но все же для возврата значений из БД анонимных типов более чем достаточно.
A>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет. Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.
Это решется с помощью метаданных. Причем метаданные могут быть выведены автоматически (следующая версия EF это будет уметь)
VD>>Так что нет никаких "частей записи". Это и есть запись. Только другая. Запрос просто преобразует набор одних записей (возможно даже множество наборов) в другой набор других записей. A>Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#.
Что значит влияет?
VD>>>>Если запрос делается над таблицами (которые тоже являются списками записей) типы полей которых, вывести тип возвращаемого значения не проблема. A>Проблема, по той простой причине, что одному типу C# может соответствовать не одна таблица БД, и напротив одна таблица может содержать данные для разных типов C#. Если ты не придумал искуственный интеллект, то проблема не решена.
Это проблема решается явным указанием того что надо получить. Ведь даже когда пишешь обычную строчку с SQL кодом представляешь себе что хочешь получить, вот и коде на C# надо указывать.
VD>>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq. A>Linq не работает не с бизнес-сущностями, а с DTO.
Linq работает с данными, или с записями если угодно (одно и тоже). DTO — костыль для изначально хреновой жирной модели.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Сам факт обработки некоторой выборки уже относится к BL, для DAL достаточно вернуть выборку в удобном для обработки виде.
A>Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет.
Это ты описываешь уже сильно высокоуровневую логику по сравнению с доставанием данных из БД.
A>Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы.
А я думал это в компетенции БД.
A>Поэтому GetById, если ничего не найдено, выкидывает исключение.
Не вижу связи этого утверждения с предыдущим.
Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).
Здравствуйте, gandjustas, Вы писали:
A>>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет. Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести. G>Это решется с помощью метаданных. Причем метаданные могут быть выведены автоматически (следующая версия EF это будет уметь)
А откуда они возьмуться? Дай угадаю, надо указывать вручную...
A>>Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#. G>Что значит влияет?
Например, у тебя есть отношение N<->M между сущностями А и В. У экземпляра класса A есть метод GetRelatedBs(), а у экземпляра класса B — GetRelatedAs() (не объязательно у них самих, возможно у внешних манипуляторов). Очевидно чтение таблицы A2B_Mapping влияет на экземпляры обоих типов. То есть тут вообще довольно хреновая ситуация, чтение этой таблицы вообще не связано с созданием новых экземпляров, только с модицикацией существующих. Читать таблицу именно как серию запросов GetRelatedX плохо по соображениям производительности.
G>Это проблема решается явным указанием того что надо получить. Ведь даже когда пишешь обычную строчку с SQL кодом представляешь себе что хочешь получить, вот и коде на C# надо указывать.
Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это.
VD>>>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq. A>>Linq не работает не с бизнес-сущностями, а с DTO. G>Linq работает с данными, или с записями если угодно (одно и тоже). DTO — костыль для изначально хреновой жирной модели.
Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать.
Здравствуйте, gandjustas, Вы писали:
A>>Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет. G>Это ты описываешь уже сильно высокоуровневую логику по сравнению с доставанием данных из БД.
Это тот уровень, с которым надо работать из BL.
A>>Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы. G>А я думал это в компетенции БД.
ИМХО ты путаешь DAL и ORM. Как бы то ни было, целостность данных должна поддерживаться уровнем ниже BL.
A>>Поэтому GetById, если ничего не найдено, выкидывает исключение. G>Не вижу связи этого утверждения с предыдущим.
Если ничего не найдено GetById, то нарушена целостность данных. Это такая попа, что тут даже исключения мало.
G>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).
QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет. Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести. G>>Это решется с помощью метаданных. Причем метаданные могут быть выведены автоматически (следующая версия EF это будет уметь) A>А откуда они возьмуться? Дай угадаю, надо указывать вручную...
Для любых метаданных есть 3 варианта (в порядке удобства использования)
1)Сограшения — отсуствие явного задания метаданных
2)Метаданные в коде (атрибуты в .NET)
3)Внешние метаданные
Внешние метаданные могут как прописываться вручную, так и генерироваться с помощью утилит.
С БД появляются некоторые особенности, так как сама БД предоставляет немалый функционал, то слабые средства вывода метаданных из соглашений и атрибутов не позволяют использовать многие возможности БД. Поэтому чаще всего применяются внешние метаданные.
Кроме того эти самые внешние метаданные могут быть использоваы для генерации схемы хранения.
A>>>Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#. G>>Что значит влияет?
A>Например, у тебя есть отношение N<->M между сущностями А и В. У экземпляра класса A есть метод GetRelatedBs(), а у экземпляра класса B — GetRelatedAs() (не объязательно у них самих, возможно у внешних манипуляторов). Очевидно чтение таблицы A2B_Mapping влияет на экземпляры обоих типов. То есть тут вообще довольно хреновая ситуация, чтение этой таблицы вообще не связано с созданием новых экземпляров, только с модицикацией существующих. Читать таблицу именно как серию запросов GetRelatedX плохо по соображениям производительности.
Я уже давно пользуюсь EF, у меня таких проблем нет.
G>>Это проблема решается явным указанием того что надо получить. Ведь даже когда пишешь обычную строчку с SQL кодом представляешь себе что хочешь получить, вот и коде на C# надо указывать. A>Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это.
Почему? Думаешь отсутствие таких пометок лучше? Все равно программист в каждом месте знает о типе записей выборки, которую он хочет получить.
Кроме того пометки по коду не разрабрасываются, а собираются в объекте-контексте.
VD>>>>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq. A>>>Linq не работает не с бизнес-сущностями, а с DTO. G>>Linq работает с данными, или с записями если угодно (одно и тоже). DTO — костыль для изначально хреновой жирной модели. A>Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать.
Вы думаете что вам надо пересобирать от этого и проблемы, другие ничего не пересобирают и живут счастливо.
VD>Тогда можно было бы просто объявить два разных анонимных типа в разных сборках и использовать их не думая где был объявлен какой переменной.
А что мешает оперировать интерфейсами? К каждому генерящемуся анонимному типу генерить еще и интерфейс который он реализует и если работать с интерфейсами то нас не волнует в какой сборке они были объявлены.
struct A:Ia1 { int a{get;set;} }
struct B:Ia2 { int a{get;set;} }
Ia1 a = new A();
Ia2 b = a;
VD>Здорово. Только вот в Guid 128 бит. Что будем делать если встретятся описания которые больше 128 бит в запакованном виде? VD>И что будем делать если один из гуидов пересечется с тем, что был сгенерирован как обычный гуид?
Гуид можно сгенерировать для строки любой длинны. А то что он не является уникальным и с чем то может пересекатся зависит от того какие требования на него наложены, может там достаточно что бы у интерфейсов с одинаковой структурой были иденичные гуиды а все остальное не важно.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет. G>>Это ты описываешь уже сильно высокоуровневую логику по сравнению с доставанием данных из БД.
A>Это тот уровень, с которым надо работать из BL.
Можете так думать, будете только усложнять себе жизнь.
A>>>Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы. G>>А я думал это в компетенции БД. A>ИМХО ты путаешь DAL и ORM. Как бы то ни было, целостность данных должна поддерживаться уровнем ниже BL.
Ниче не понял. Причем тут DAL и ORM ? БД — уровень ниже BL?
A>>>Поэтому GetById, если ничего не найдено, выкидывает исключение. G>>Не вижу связи этого утверждения с предыдущим. A>Если ничего не найдено GetById, то нарушена целостность данных. Это такая попа, что тут даже исключения мало.
Почему? Какая разница методу GetById почему его вызвали с Id которого нет в базе?
G>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject). A>QueryObject нужен для нетипичных запросов, типа запросов для отчётов.
А кто мешает GetById написать через тот же QueryObject ? Вам ведь все равно писать запрос придется.
A>Использовать его для всего подряд просто неправильно.
А обоснования? (рассказываю секрет: IQueryable реализует именно такую абстракцию)
Здравствуйте, gandjustas, Вы писали:
G>Для любых метаданных есть 3 варианта (в порядке удобства использования) G>1)Сограшения — отсуствие явного задания метаданных G>2)Метаданные в коде (атрибуты в .NET) G>3)Внешние метаданные G>Внешние метаданные могут как прописываться вручную, так и генерироваться с помощью утилит. G>С БД появляются некоторые особенности, так как сама БД предоставляет немалый функционал, то слабые средства вывода метаданных из соглашений и атрибутов не позволяют использовать многие возможности БД. Поэтому чаще всего применяются внешние метаданные. G>Кроме того эти самые внешние метаданные могут быть использоваы для генерации схемы хранения.
Получается левой рукой правое ухо. На основе формального описания генерировать внешние метаданные на основе которых генерировать C# код ис хему БД. Проще и правильнее генерировать сразу код и схему БД на основе формального описания.
A>>Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это. G>Почему? Думаешь отсутствие таких пометок лучше?
Думаю, лучше внешние метаданные.
G>Все равно программист в каждом месте знает о типе записей выборки, которую он хочет получить.
Откуда знает, помнит?
G>Кроме того пометки по коду не разрабрасываются, а собираются в объекте-контексте.
А так как объхектов много, то всё же разбрасываются.
A>>Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать. G>Вы думаете что вам надо пересобирать от этого и проблемы, другие ничего не пересобирают и живут счастливо.
Выше я про M<->N уже написал. Пересобирать таки надо.
Здравствуйте, gandjustas, Вы писали:
A>>Это тот уровень, с которым надо работать из BL. G>Можете так думать, будете только усложнять себе жизнь.
Ну а альтернатива какая? Усложнить BL введя логику обработки повреждённых данных? Что-то не впечатляет.
A>>ИМХО ты путаешь DAL и ORM. Как бы то ни было, целостность данных должна поддерживаться уровнем ниже BL. G>Ниче не понял. Причем тут DAL и ORM ? БД — уровень ниже BL?
БД, уровень, безусловно ниже BL.
A>>Если ничего не найдено GetById, то нарушена целостность данных. Это такая попа, что тут даже исключения мало. G>Почему? Какая разница методу GetById почему его вызвали с Id которого нет в базе?
Разница такая, что его не имеют права вызывать с Id которого нет в базе. Если подобное случилось, значит где-то баг, который надо исправить.
A>>Использовать его для всего подряд просто неправильно. G>А обоснования? (рассказываю секрет: IQueryable реализует именно такую абстракцию)
Ты всегда приводишь IQueryable как обоснование своей позиции
Открою секрет — в базе данных есть индексы. Нельзя одинаково эффективно выполнять выборку по разным условиям. Поэтому, надо явно выделять эффективные случаи в специализированные методы доступа. Если этого не делать, получается абсолютно некотроллируемый рост похожих запросов. Оптимизировать базу под все из них невозможно, а если подумать, все и не нужны вовсе. Только вот в твоём варианте, какие лучше нигде в интерфейсе DAL не светится.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Для любых метаданных есть 3 варианта (в порядке удобства использования) G>>1)Сограшения — отсуствие явного задания метаданных G>>2)Метаданные в коде (атрибуты в .NET) G>>3)Внешние метаданные G>>Внешние метаданные могут как прописываться вручную, так и генерироваться с помощью утилит. G>>С БД появляются некоторые особенности, так как сама БД предоставляет немалый функционал, то слабые средства вывода метаданных из соглашений и атрибутов не позволяют использовать многие возможности БД. Поэтому чаще всего применяются внешние метаданные. G>>Кроме того эти самые внешние метаданные могут быть использоваы для генерации схемы хранения.
A>Получается левой рукой правое ухо. На основе формального описания генерировать внешние метаданные на основе которых генерировать C# код ис хему БД. Проще и правильнее генерировать сразу код и схему БД на основе формального описания.
А почему формальное описание не может служить метаданными?
A>>>Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это. G>>Почему? Думаешь отсутствие таких пометок лучше? A>Думаю, лучше внешние метаданные.
Внешние метаданные — самые неудобные в использовании в программе, указание типа — является своего рода метаданными в коде.
Кстати при наличии внешних метаданных можно аннотации типов сгенерировать (что собственно и делается).
G>>Все равно программист в каждом месте знает о типе записей выборки, которую он хочет получить. A>Откуда знает, помнит?
Хорошо если помнит, иначе ему придется реверсить то что понаписано. В этом собственно и заключается основная проблема при работе с SQL.
DAL в виде GetByIi, GetAll и прочих методов создается как раз чтобы сконцентрировать этот sacral knoweledge в одном месте. Это позволяет программисту понимать что происходит, но не дает никаких гарантий (не проверяется при компиляции).
G>>Кроме того пометки по коду не разрабрасываются, а собираются в объекте-контексте. A>А так как объхектов много, то всё же разбрасываются.
Да ну? Объект-контекст — один (ну максимум два) и генерируется автоматически.
A>>>Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать. G>>Вы думаете что вам надо пересобирать от этого и проблемы, другие ничего не пересобирают и живут счастливо. A>Выше я про M<->N уже написал. Пересобирать таки надо.
Это вы так думаете. Мне например ничего пересобирать ни разу не приходилось.
Здравствуйте, gandjustas, Вы писали:
A>>Получается левой рукой правое ухо. На основе формального описания генерировать внешние метаданные на основе которых генерировать C# код ис хему БД. Проще и правильнее генерировать сразу код и схему БД на основе формального описания. G>А почему формальное описание не может служить метаданными?
А тогда о чём ты споришь? Я именно это с самого начала и предлагаю.
G>Внешние метаданные — самые неудобные в использовании в программе, указание типа — является своего рода метаданными в коде. G>Кстати при наличии внешних метаданных можно аннотации типов сгенерировать (что собственно и делается).
Внешние метанданные неудобные если служат для конфигурации программы, а не для её генерации.
G>DAL в виде GetByIi, GetAll и прочих методов создается как раз чтобы сконцентрировать этот sacral knoweledge в одном месте. Это позволяет программисту понимать что происходит, но не дает никаких гарантий (не проверяется при компиляции).
Вот. А если использовать генерацию кода, то вероятность рассинхронизации названия и смысла падает до нуля.
Здравствуйте, adontz, Вы писали:
A>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет.
Какая на фиг аналогия? Анонимные типы — это и есть реализация записей в C#. В Немерле для тех же целей я использую кортежи.
A>Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.
Ты уперся в свое однобокое представление. Если хочешь понять мои слова, тебе прийдется немного перестроить свое сознание. Заставлять тебя я точно не буду. Так что если не хочешь напрягать мыслительный аппарат, то продолжай повторять эту же мантру. Мешать не буду.
VD>>Так что нет никаких "частей записи". Это и есть запись. Только другая. Запрос просто преобразует набор одних записей (возможно даже множество наборов) в другой набор других записей.
A>Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#.
Это твоя мантра. Меж тем надо понять простую истину. Ложки нет. Тфу ты... Объектов нет! Есть записи которые один в один отражаются в простые плоские объекты или в анонимные типы (тоже весьма простые и плоские).
Как только это понимание придет в твою голову, то все идеологические проблемы сразу же исчезнут.
Пойми ООП просто не причем. Для отображения в БД лучше подходя просты плоские типы.
VD>>>>Если запрос делается над таблицами (которые тоже являются списками записей) типы полей которых, вывести тип возвращаемого значения не проблема.
A>Проблема, по той простой причине, что одному типу C# может соответствовать не одна таблица БД, и напротив одна таблица может содержать данные для разных типов C#. Если ты не придумал искуственный интеллект, то проблема не решена.
Это или ты выдумал сам, или почерпнул от маньяков ОРМ-щиков.
Не надо отображать объекты на БД. Это тупиковый путь. Повторяться надоело. Прочти еще раз мои слова. Не поймешь, значит тебе не надо.
VD>>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.
A>Linq не работает не с бизнес-сущностями, а с DTO.
В задницу твои бизнес-сущности. Линк обрабатывает данные. В том числе и лежащие в БД. А ты погряз в догмах ООП. Ты не понял ни слова из этой темы. Счастливо оставаться в своих заблуждениях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести. VD>Ты уперся в свое однобокое представление. Если хочешь понять мои слова, тебе прийдется немного перестроить свое сознание. Заставлять тебя я точно не буду. Так что если не хочешь напрягать мыслительный аппарат, то продолжай повторять эту же мантру. Мешать не буду.
Влад, ты рассуждаешь так, как будто кроме DAL ничего нет. Что потом делать с твоими анонимными типами?
VD>Не надо отображать объекты на БД.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Это тот уровень, с которым надо работать из BL. G>>Можете так думать, будете только усложнять себе жизнь. A>Ну а альтернатива какая? Усложнить BL введя логику обработки повреждённых данных? Что-то не впечатляет.
A>>>ИМХО ты путаешь DAL и ORM. Как бы то ни было, целостность данных должна поддерживаться уровнем ниже BL. G>>Ниче не понял. Причем тут DAL и ORM ? БД — уровень ниже BL? A>БД, уровень, безусловно ниже BL.
Так и пусть целостность данных на уровне БД будет, и не надо BL усложнять. И волки сыты и овцы — целки.
A>>>Если ничего не найдено GetById, то нарушена целостность данных. Это такая попа, что тут даже исключения мало. G>>Почему? Какая разница методу GetById почему его вызвали с Id которого нет в базе? A>Разница такая, что его не имеют права вызывать с Id которого нет в базе. Если подобное случилось, значит где-то баг, который надо исправить.
Почему не имеют? Это же просто метод доступа к данным, какая вообще разница зачем его вызывают? Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.
A>>>Использовать его для всего подряд просто неправильно. G>>А обоснования? (рассказываю секрет: IQueryable реализует именно такую абстракцию)
A>Ты всегда приводишь IQueryable как обоснование своей позиции
Ага, потому что это работающее решение. Даже когда не ыбло IQueryable я писал свои QueryObjects.
A>Открою секрет — в базе данных есть индексы. Нельзя одинаково эффективно выполнять выборку по разным условиям. Поэтому, надо явно выделять эффективные случаи в специализированные методы доступа.
Вау, оказывается DAL — это premature optimization для работы с БД?
A>Если этого не делать, получается абсолютно некотроллируемый рост похожих запросов. Оптимизировать базу под все из них невозможно, а если подумать, все и не нужны вовсе.
А под все оптимизировать и не надо, надо только под тормозящие. Для этого профайлер в зубы и смотрим, обычно в программе меньше пяти Особо Торозящих Запросов.
Кроме того оптимизация работы с БД начинается с правильного построения проекций и фильтров, потом идет работа с индексами, если уж совсем не помогло, то начинается оптимизация схемы хранения (возможно использование индесированных вьюх, предвычисления на триггерах и прочее).
A>Только вот в твоём варианте, какие лучше нигде в интерфейсе DAL не светится.
Не надо преждевременной оптимизацие заниматься.
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, VladD2, Вы писали:
VD>>Тогда можно было бы просто объявить два разных анонимных типа в разных сборках и использовать их не думая где был объявлен какой переменной.
D>А что мешает оперировать интерфейсами? К каждому генерящемуся анонимному типу генерить еще и интерфейс который он реализует и если работать с интерфейсами то нас не волнует в какой сборке они были объявлены.
А смысл? Основные функции записей — это сравнение и копирование. Как этому помогут интерфейсы?
Да и опять же сгенерировать одинаковые гуиды для одинаковых записей нельзя.
VD>>Здорово. Только вот в Guid 128 бит. Что будем делать если встретятся описания которые больше 128 бит в запакованном виде? VD>>И что будем делать если один из гуидов пересечется с тем, что был сгенерирован как обычный гуид? D>Гуид можно сгенерировать для строки любой длинны.
Это нонсенс.
D>А то что он не является уникальным и с чем то может пересекатся зависит от того какие требования на него наложены,
Требование одно. Структурная идентичность. Гуиды должны совпадать только у тех типов которые структурно идентичны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.
Нет, целостность данных — должна контролироваться в DAL и БД. Отствие записи с нужным ID — это исключительная ситуация, и DAL в таком случае должен выбрасывать исключение. И вот дальше уже да, дело бизнес-логики как обрабатывать это исключение.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Получается левой рукой правое ухо. На основе формального описания генерировать внешние метаданные на основе которых генерировать C# код ис хему БД. Проще и правильнее генерировать сразу код и схему БД на основе формального описания. G>>А почему формальное описание не может служить метаданными?
A>А тогда о чём ты споришь? Я именно это с самого начала и предлагаю.
Так оно и так используется (в Linq2SQL сейчас есть, в EF будет), правда в ограниченном объеме.
G>>Внешние метаданные — самые неудобные в использовании в программе, указание типа — является своего рода метаданными в коде. G>>Кстати при наличии внешних метаданных можно аннотации типов сгенерировать (что собственно и делается). A>Внешние метанданные неудобные если служат для конфигурации программы, а не для её генерации.
Генерация по метаданным — способ победить некоторые неудобства.
Например контексты Linq2SQL и EF можно использовать без генератора.
G>>DAL в виде GetByIi, GetAll и прочих методов создается как раз чтобы сконцентрировать этот sacral knoweledge в одном месте. Это позволяет программисту понимать что происходит, но не дает никаких гарантий (не проверяется при компиляции). A>Вот. А если использовать генерацию кода, то вероятность рассинхронизации названия и смысла падает до нуля.
Это нужно очень крутое описание чтобы сгенерировать кучу методов GetById, GetAll, FindByDickLength итп.
Здравствуйте, gandjustas, Вы писали:
G>Так и пусть целостность данных на уровне БД будет, и не надо BL усложнять. И волки сыты и овцы — целки.
Если ты позволяешь GetById возвращать null, ты усложняешь BL обработкой этого случая либо скрываешь ошибку необработкой.
A>>Разница такая, что его не имеют права вызывать с Id которого нет в базе. Если подобное случилось, значит где-то баг, который надо исправить. G>Почему не имеют? Это же просто метод доступа к данным, какая вообще разница зачем его вызывают? Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.
BL не должен содержать код обработки нецелостных данных.
A>>Открою секрет — в базе данных есть индексы. Нельзя одинаково эффективно выполнять выборку по разным условиям. Поэтому, надо явно выделять эффективные случаи в специализированные методы доступа. G>Вау, оказывается DAL — это premature optimization для работы с БД?
Нет. Но DAL не может состоять из одного только метода Query.
A>>Если этого не делать, получается абсолютно некотроллируемый рост похожих запросов. Оптимизировать базу под все из них невозможно, а если подумать, все и не нужны вовсе. G>А под все оптимизировать и не надо, надо только под тормозящие. Для этого профайлер в зубы и смотрим, обычно в программе меньше пяти Особо Торозящих Запросов.
Тормозящие понятие относительное. Ты этоо измеряешь, может, в секундах, а я сталкивался с творениями любителей HQL и прочих "вкусностей", которые так сильно тормозили, что приходилось менять бизнес-процессы. Оптимальные запросы должны быть выделены. Это не прихоть, а практическая необходимость.
A>>Только вот в твоём варианте, какие лучше нигде в интерфейсе DAL не светится. G>Не надо преждевременной оптимизацие заниматься.
Она не преждевременная, так как схема БД (включая индексы) уже есть.
