Здравствуйте, VladD2, Вы писали:
VD>Семантика тут тоже не причем. Нужные операции есть и сейчас. Просто то что раньше было запрещено будет разрешено.
Продолжаю не понимать. Операция раньше делала что-то по одним правилам, а теперь стала по другим. Что это если не изменение семантики ??? Тут ведь всё надо будет переделывать/передоказывать. Начиная с верификатора, и далее со всеми остановками...
Здравствуйте, Lloyd, Вы писали:
L>Кортежи тоже не панацея.
Панацея тут не причем. Кортежи — это тип данных удобный во многих (но не во всех) случаях. На работу с БД кортежи ложатся отлично.
L>Если я не ошибаюсь, в кортежах обращение к полю фактически происходит по его индексу, это лучше чем ничего, но гораздо хуже, чем полноценные именованые поля.
Ошибаешься. Точнее в Немерле можно пользоваться и индексным доступом (при условии что в качестве индекса используется константа). Но реально в Немерле обычно используются паттерн-матчинг для декомпозиции кортежа. Физически же у кортежа есть предопределенные поля (речь идет о реализации под дотнетом).
L>Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?
Что за сотрудники покупателя? К тому же нужно понимать о какой БД идет речь.
VD>>Данные нужно передавать через границы процессов и даже на другие компьюетры. При этом передача любых ненужных данных становится дорогим удовольствием.
L>Значит ли это, что если у нас нет необходимости получать объекты по ссылкам, то вытаскивание всего объекта целиком — не проблема?
Я вообще не понял что ты сказал.
L>Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?
От конкретного источника конечно можно абстрагироваться. Но от структуры хранения никуда не деться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, drol, Вы писали:
D>Продолжаю не понимать. Операция раньше делала что-то по одним правилам, а теперь стала по другим. Что это если не изменение семантики ??? Тут ведь всё надо будет переделывать/передоказывать. Начиная с верификатора, и далее со всеми остановками...
Операция раньше копировала, и теперь копирует. Просто раньше она была применима только для объектов одного типа, а теперь и для разных.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Операция раньше копировала, и теперь копирует. Просто раньше она была применима только для объектов одного типа, а теперь и для разных.
Это и есть изменение семантики. Надо менять верификатор и т.д. Про что Хейльсберг и говорил.
Tom>У нас сейчас планируется первая часть рефакторинга — полное переползание на .NET (да да да, только сейчас... ((( ) Tom>будут и другие, связанные с базой. Через годик. Может тогда на рынке будут достойные решения работы с БД.
Здравствуйте, IT, Вы писали:
IT>Что же касается бизнес логики на TSQL, которую ты здесь привёл, то это одно из двух: либо пережиток старого, либо дурь. Надеюсь первое. Разумного оправдания такой практике сегодня нет.
Здравствуйте, adontz, Вы писали:
A>Вовсе нет. Если я хочу получить конкретный элемент по идентификатору, этот элемент в базе должен быть. В противном случае, имеет место логическая ошибка: неправильное получение идентификатора элемента или состояние гонки. Отсутствие конкретного элемента и пустой список элементов очень разные ситуации.
Это зависит от того, откуда мы получаем идентификатор. Если идентификатор приходит откуда-то из-вне, то этому "далёку" будет положить на наше исключение. Например, какой смысл кидать пользователю исключение, если он ввел неправильный логин?
Здравствуйте, VladD2, Вы писали:
VD>Вот эта логика мне всегда очень нравилась. Если код написал некий Вася из Майкрософт, то ты будешь ждать хоть целую вечность. Если код написал кто-то независимый, то ему конечно доверять нельзя. VD>
Логика тут нормальная. Пользователей васиного из Майкрософт кода будет на несколько порядков больше, чем у какой-то левой библиотеки. Как следствие, больше вероятность того, что кто-то другой до тебя найдет workaround твоих проблем и опубликует его в интернете.
Здравствуйте, MozgC, Вы писали:
MC>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.
Это называется "реализация логики на исключениях"
MC>Вообще так можно про все сказать "что тут исключительного". К примеру пытаемся прочитать файл, а такого файла нет (его уже пользователь удалил), ну а что тут исключительного, давайте признак возвращать.
Как минимум, разница в том, что для файла существует метод "bool Exists(FileName)".
Здравствуйте, MozgC, Вы писали:
MC>Нет, это называется использовать исключения там где нужно.
Использовать исключения там где нужно — это когда на этапе написания программы ты не можешь предвидеть условия возникновения исключительной ситуации, но можешь эту ситуацию обнаруживать. Например, если при написании программы ты можешь предвидеть отсутствие файла, то надо явно проверять существование этого файла, а не обрабатывать FileNotFoundException.
Здравствуйте, MozgC, Вы писали:
MC>Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БД (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?
Если производителя нет, а он обязательно должен быть, то есть у нас налицо баг в данных, либо в коде, — то всё нормально. Если же производителя может и не быть (например, если он был удален стандартным способом) и данная ситуация не говорит о наличии бага, то не надо было доводить ситуацию до критической. Вместо этого надо было сначала убедиться в том, что производитель существует. Но у этого подхода есть две проблемы: лишний запрос к БД и параллелизм. Для решения этих проблем делают метод GetByID, возвращающий признак отсутствия данных. В отличии от исключений этот признак явный.
Здравствуйте, VladD2, Вы писали:
L>>Кортежи тоже не панацея.
VD>Панацея тут не причем. Кортежи — это тип данных удобный во многих (но не во всех) случаях. На работу с БД кортежи ложатся отлично.
Разве отлично? В базах данных кортеж — это набор именованых значений. В языках программирования — упорядоченный набор значений. По-моему отличия достаточно значительные.
L>>Если я не ошибаюсь, в кортежах обращение к полю фактически происходит по его индексу, это лучше чем ничего, но гораздо хуже, чем полноценные именованые поля.
VD>Ошибаешься. Точнее в Немерле можно пользоваться и индексным доступом (при условии что в качестве индекса используется константа). Но реально в Немерле обычно используются паттерн-матчинг для декомпозиции кортежа.
Разве это суть важно, что доступ не по индексу, а через паттерн матчинг, но все равно по тому же индексу.
VD>Физически же у кортежа есть предопределенные поля (речь идет о реализации под дотнетом).
First, Second, Third? Ты об этом говоришь?
L>>Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?
VD>Что за сотрудники покупателя? К тому же нужно понимать о какой БД идет речь.
Под кастомером я в данном случае имел в виду заказчика. Заказчиком является фирма, на ней работают сотрудники.
Схема самая простая: сотрудник (Employee) полем CustomerID ссылается на ID в таблице Customer
VD>>>Данные нужно передавать через границы процессов и даже на другие компьюетры. При этом передача любых ненужных данных становится дорогим удовольствием.
L>>Значит ли это, что если у нас нет необходимости получать объекты по ссылкам, то вытаскивание всего объекта целиком — не проблема?
VD>Я вообще не понял что ты сказал.
Если у нас есть таблица заказчиков и нам в приложении не нужно получать информацию из других таблиц, то можно ли в этом случае грузить сущность целиком?
L>>Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?
VD>От конкретного источника конечно можно абстрагироваться. Но от структуры хранения никуда не деться.
Целиком и полностью нельзя, но от каких-то деталей бизнес-логику все-таки можно изолировать.
Здравствуйте, VladD2, Вы писали:
C>>У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей
VD>Чем изобретать велосипеды проще иметь реплики БД.
То есть у вас сиквел в Интернет?
Надеюсь, хот через ВПН?
Здравствуйте, mrTwister, Вы писали:
A>>Вовсе нет. Если я хочу получить конкретный элемент по идентификатору, этот элемент в базе должен быть. В противном случае, имеет место логическая ошибка: неправильное получение идентификатора элемента или состояние гонки. Отсутствие конкретного элемента и пустой список элементов очень разные ситуации.
T>Это зависит от того, откуда мы получаем идентификатор. Если идентификатор приходит откуда-то из-вне, то этому "далёку" будет положить на наше исключение. Например, какой смысл кидать пользователю исключение, если он ввел неправильный логин?
Здравствуйте, mrTwister, Вы писали:
T>Советую обратить внимание на LightSpeed
Посмотрел вот снова второй раз в жизни. Ребята продвинулись за пару лет. Дизайнеров студийных добавили, Linq прикрутили, умных слов в раздел поддерживаемых паттернов добавили. В общем развиваются
А так ничего сверхоригинального. Обычная библиотечка куда напихали всего побольше с не очень удобной как по мне работой с данными. Вся их скорость основана на динамической генерации кода при помощи LCG, ну дык все тоже же самое с помощью Emit уже кучу лет есть в прекрасной библиотеке BLToolkit. А всякие репозитории и юнит-оф-ворки можно и самому накрутить в приложении если это нужно для приложения. А еще я очень не люблю когда меня заставляют наследоваться от чего то чтобы работать с СУБД...
Здравствуйте, Lloyd, Вы писали:
L>Разве отлично? В базах данных кортеж — это набор именованых значений. В языках программирования — упорядоченный набор значений. По-моему отличия достаточно значительные.
В базах данных используются записи, а не кортежи. Путаница идет из-за того, что в работах по реляционной алгебре использовалось понятие кортеж. Однако эти типы очень похожи. Разница действительно только в том, что у записей элементы именованы и к ним можно обращаться по именам.
Самое важное, что структура записи и кортежа может совпадать. Это позволяет выбирать и хранить значения жертвуя именами полей. На практике оказывается, что это не такая уж серьезная жертва.
L>Разве это суть важно, что доступ не по индексу, а через паттерн матчинг, но все равно по тому же индексу.
Нет там никаких индексов. Индекс в данном случае — это просто порядковый номер. Его даже перебрать в цикле нельзя.
Собственно, что тут обсуждать. Можешь поглядеть как кортежи используются в немерле для доступа к данным в MS SQL Server: http://nemerle.org/svn/nemerle/trunk/Linq/Testes/Linq2SqlTests.n
VD>>Физически же у кортежа есть предопределенные поля (речь идет о реализации под дотнетом).
L>First, Second, Third? Ты об этом говоришь?
Field1, Field2, ..., Fieldn
L>>>Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?
VD>>Что за сотрудники покупателя? К тому же нужно понимать о какой БД идет речь.
L>Под кастомером я в данном случае имел в виду заказчика. Заказчиком является фирма, на ней работают сотрудники. L>Схема самая простая: сотрудник (Employee) полем CustomerID ссылается на ID в таблице Customer
Бредовая какая-то база (или ситуация). Какой смысл учитывать чужих сотрудников?
Запрос в данном случае будет совершенно примитивным:
def custs = linq <# from c in customers from e in c.Employees select (e.FirstName, e.SurName) #>;
def toLi(fName, sName) { $"<li>fName, sName</li>" }
def html = $<#<ul> ..$(custs; "\n"; toLi) </ul>#>;
или
def custs = linq <# from c in customers
join e on in employees on c.ID == e.CustomerID
select (e.FirstName, e.SurName) #>;
def html = $<#<ul> ..$(custs; "\n"; (fName, sName) => $"<li>fName, sName</li>") </ul>#>;
L>Если у нас есть таблица заказчиков и нам в приложении не нужно получать информацию из других таблиц, то можно ли в этом случае грузить сущность целиком?
Что запросишь, то получишь. Все равно не понимаю смысла.
L>>>Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?
VD>>От конкретного источника конечно можно абстрагироваться. Но от структуры хранения никуда не деться.
L>Целиком и полностью нельзя, но от каких-то деталей бизнес-логику все-таки можно изолировать.
Зачем бизнес-логику оберегать от знания того что она обрабатывает? Вот от конкретного сервера можно спрятать. А то что у нас есть те самые кастомеры и емплоеры — это базовые понятия для бизнес-логики. И не стоит скрывать эту информацию. Обернув все в никчемные функции вроде GetCuatomerByFitstName(...) ты нисколко не скроишь эту информацию. Ты только заставишь программиста напрягать мозг еще больше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mrTwister, Вы писали:
T>Логика тут нормальная. Пользователей васиного из Майкрософт кода будет на несколько порядков больше, чем у какой-то левой библиотеки. Как следствие, больше вероятность того, что кто-то другой до тебя найдет workaround твоих проблем и опубликует его в интернете.
Это миф. Зайди на баг-треккер Майкрософт и убедись сам сколько багов годами не исправляются.
Да и предпосылка ложная. Скажем пользователей Гибернэйта на сегодня сильно больше чем линка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
L>>>Мы сами подобное используем, я имею в виду создание отдельных PE для отдельных страниц. И меня совершенно не радует созерцать кучу одноразовых классов. Так что так уж однозначно называть этот способ правильным я бы не стал. G>>Если классы очень похожи, то вполне можно убрать дублирование наследованием.
L>Еще и наследование сюда тащить? Нее, ф топку.
А чем наследование плохо?
Общность данных очень удобно выражаать через наследование или реализацию интерфейсов.
G>>>>>>Это если запись маленькая. Если в записи фигурируют image, varbinary, ntext и подобное, то читать эту запись полностью становится достаточно дорого. L>>>>>Ну это скорее исключение, в основном все ограничивается числами и строками. G>>>>Именно такие исключения создают тормоза в программах. В варианте GetById где будет определяться проекция? L>>>Исключения, в силу своей исключительнсти, создают тормоза в исключительных случаях, т.е. редко. G>>Учитывая связанные сущности — часто. G>>Вам практически никогда не удастся сохранить чистоту DAL, не протягивая туда детали business-logic и presentation и при этом получить нормальное быстродействие. L>См. выше на реплику, на которую я отвечал. В ней ничего про связанные энтити не было
Надо проблему целиком рассматривать.
Проблема не в GetById, а в тому что такой подход вынужнает работать с целыми объектами, соотвествующими сущностям предметной области.
В DDD даже придумали костыль — aggregation roots назвали.
G>>>>>>Кроме того одной записи для отображения чаще всего недостаточно, обычно тянется некоторый набор связанных записей и на них наклдаывается проекция или группировка. При подходе с GetById накладывать проекции и группировки нельзя, иначе получится протаскивание деталей presentation в DAL (та самая каша, о которой говорит Tom). L>>>>>Ок. Что взамен? По каждый view (не бд, а ui) — пачка presentation классов? G>>>>Не пачка, а один. Это сильно способствует упрощению кода view. L>>>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name. G>>Для пар "ключ-значение" уже есть классы. L>Есть, но я не о них. Часто нужно более двух полей, тут то начинают появляться нелепые классы типа CustomerInfo, ContactInfo, etc
Посмотрел свои проекты. По сравнению с случаем выборки пар ключ-значение выборка трех полей из БД осуществляется гораздо реже.
Здравствуйте, VladD2, Вы писали:
L>>Разве отлично? В базах данных кортеж — это набор именованых значений. В языках программирования — упорядоченный набор значений. По-моему отличия достаточно значительные.
VD>В базах данных используются записи, а не кортежи. Путаница идет из-за того, что в работах по реляционной алгебре использовалось понятие кортеж. Однако эти типы очень похожи. Разница действительно только в том, что у записей элементы именованы и к ним можно обращаться по именам.
По-моему, это очень существенная разница.
VD>Самое важное, что структура записи и кортежа может совпадать. Это позволяет выбирать и хранить значения жертвуя именами полей. На практике оказывается, что это не такая уж серьезная жертва.
На практике? Не напомнишь хотя бы одну библиотеку доступа к данным, где не было бы доступа к зачению поля по имени?
L>>Разве это суть важно, что доступ не по индексу, а через паттерн матчинг, но все равно по тому же индексу.
VD>Нет там никаких индексов. Индекс в данном случае — это просто порядковый номер. Его даже перебрать в цикле нельзя. VD>Собственно, что тут обсуждать. Можешь поглядеть как кортежи используются в немерле для доступа к данным в MS SQL Server: VD>http://nemerle.org/svn/nemerle/trunk/Linq/Testes/Linq2SqlTests.n
Не поленился и посмотрел, но не нашел ни одного теста, в котором бы демонстрировался доступ к отдельному полю в возвращаемом кортеже.
VD>>>Физически же у кортежа есть предопределенные поля (речь идет о реализации под дотнетом).
L>>First, Second, Third? Ты об этом говоришь?
VD>Field1, Field2, ..., Fieldn
Ты действительно считаешь, что допустимо иметь такие имена для полей?
L>>>>Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?
VD>>>Что за сотрудники покупателя? К тому же нужно понимать о какой БД идет речь.
L>>Под кастомером я в данном случае имел в виду заказчика. Заказчиком является фирма, на ней работают сотрудники. L>>Схема самая простая: сотрудник (Employee) полем CustomerID ссылается на ID в таблице Customer
VD>Бредовая какая-то база (или ситуация). Какой смысл учитывать чужих сотрудников?
Компания, для которой я пишу сейчас проект, занимается предоставлением IT-услуг компаниям. Для них информация о персонале важнп. Так что схема взята из жизни, а потому не бредова.
VD>Запрос в данном случае будет совершенно примитивным: VD>
VD>def custs = linq <# from c in customers from e in c.Employees select (e.FirstName, e.SurName) #>;
VD>def toLi(fName, sName) { $"<li>fName, sName</li>" }
VD>def html = $<#<ul> ..$(custs; "\n"; toLi) </ul>#>;
VD>
VD>или VD>
VD>def custs = linq <# from c in customers
VD> join e on in employees on c.ID == e.CustomerID
VD> select (e.FirstName, e.SurName) #>;
VD>def html = $<#<ul> ..$(custs; "\n"; (fName, sName) => $"<li>fName, sName</li>") </ul>#>;
VD>
Не, так писать не модно еще со времен коассического ASP. Нынче рулит разделение на model-view-controller.
L>>Если у нас есть таблица заказчиков и нам в приложении не нужно получать информацию из других таблиц, то можно ли в этом случае грузить сущность целиком?
VD>Что запросишь, то получишь. Все равно не понимаю смысла.
Ладно, проехали.
L>>>>Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?
VD>>>От конкретного источника конечно можно абстрагироваться. Но от структуры хранения никуда не деться.
L>>Целиком и полностью нельзя, но от каких-то деталей бизнес-логику все-таки можно изолировать.
VD>Зачем бизнес-логику оберегать от знания того что она обрабатывает? Вот от конкретного сервера можно спрятать. А то что у нас есть те самые кастомеры и емплоеры — это базовые понятия для бизнес-логики. И не стоит скрывать эту информацию. Обернув все в никчемные функции вроде GetCuatomerByFitstName(...) ты нисколко не скроишь эту информацию. Ты только заставишь программиста напрягать мозг еще больше.
Прятание запросов типа GetCuatomerByFitstName не обсуждается. Речь идет о сокрытии деталей маппинга полей сущностей на поля таблиц базы данных.
Здравствуйте, gandjustas, Вы писали:
G>>>Если классы очень похожи, то вполне можно убрать дублирование наследованием.
L>>Еще и наследование сюда тащить? Нее, ф топку. G>А чем наследование плохо? G>Общность данных очень удобно выражаать через наследование или реализацию интерфейсов.
Прежде всего негибкостью — нет множественного наследования. Во-вторых, нунужным усложнением.
L>>>>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name. G>>>Для пар "ключ-значение" уже есть классы. L>>Есть, но я не о них. Часто нужно более двух полей, тут то начинают появляться нелепые классы типа CustomerInfo, ContactInfo, etc G>Посмотрел свои проекты. По сравнению с случаем выборки пар ключ-значение выборка трех полей из БД осуществляется гораздо реже.
У меня другая статистика. У нас оч. тяжелые страницы и много аякса и и потому для каждой сущности, отображаемой на странице, приходится делать ее (сущности) урезаный вариант, а это и приводит в появлению этих ненавистных CustomerInfo, ContactInfo, etc
