Здравствуйте, VladD2, Вы писали:
VD>Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0?
По крайней мере будут ее зачатки. Если два интерфейса с одинаковой структурой пометить одинаковым Guid то для clr они будут эквивалентными.
VD>Я слышал обратное. В прочем я слышал это о C#.
Глядишь к 5 версии чего нибудь сделают.
Здравствуйте, adontz, Вы писали:
A>ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет. К тому же ты пропустил вариант "просто какие-то табличные данные", что весьма типично для отчётов.
Вы описываете то что относиться к бизнес-логике. От DAL в идеале нужно только получать IQueryable<T>, вызывать методы Delete, Update и Insert, которые также могут принимать IQueryable<T> в качестве удаляемых\изменяемых\вставляемых значений.
A>>>SQL из C# сгенерировать можно, но поддерживать это хозяйство сложно. Много чего приходится указывать вручную. Нет никакого нормального механизма обновления схемы без потери данных. Tom>>Обновление схемы — это отдельный вопрос. Вопрос решаемый разными путями, предлагаю обсуждать не тут. A>Я уже выше отписался, почему считаю этот вопрос актуальным.
Тем не менее этот вопрос никак не свзяан со способом работы с даными.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, adontz, Вы писали:
A>>ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет. К тому же ты пропустил вариант "просто какие-то табличные данные", что весьма типично для отчётов. G>Вы описываете то что относиться к бизнес-логике.
Вовсе нет. Если я хочу получить конкретный элемент по идентификатору, этот элемент в базе должен быть. В противном случае, имеет место логическая ошибка: неправильное получение идентификатора элемента или состояние гонки. Отсутствие конкретного элемента и пустой список элементов очень разные ситуации.
A>>Я уже выше отписался, почему считаю этот вопрос актуальным. G>Тем не менее этот вопрос никак не связан со способом работы с данными.
Методы работы с БД должны учитывать возможность изменения схемы. Использовать другие методы, значит отрицать возможность рефакторинга БД и, тем самым, существенно его удорожать.
Здравствуйте, Tom, Вы писали:
VD>>Ну, дык, этот же код он будет поддерживать. Тебе то что? Tom>Если вдруг мы решим его использовать то ждать пока кто то пофиксит там баг который для нас является критическим конечно мы не будем.
Вот эта логика мне всегда очень нравилась. Если код написал некий Вася из Майкрософт, то ты будешь ждать хоть целую вечность. Если код написал кто-то независимый, то ему конечно доверять нельзя.
Tom>ну и просто что бы оценить сложность решения хотелось бы понять его обьём.
Понятие "сложность" относительное понятие. Сложное для одного не сложно для другого. Так что это вообще смысла не имеет.
Почему ты, к примеру, не интересующийся сложностью того же MS SQL Server? Почему тебя вдруг так начала интересовать сложность библиотечки доступа к данным?
VD>>Тут важен не объем кода, а его качество (читаемость, структурированость). Tom>Кто же спорит
Ну, дык, а что тогда спрашивать вообще не касающиеся тебя детали?
Пойми кода может быть 2 килобайта, но ты в них вообще разобраться не сможешь. Как измерить сложность для тебя?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dotneter, Вы писали:
VD>>Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0? D>По крайней мере будут ее зачатки. Если два интерфейса с одинаковой структурой пометить одинаковым Guid то для clr они будут эквивалентными.
Это немного не то. Точнее совсем не то. Во-первых, у интерфейсов нет структуры, так что их эквивалентности добиться не сложно. Главное чтобы совпадали сигнатуры и позиции методов.
Во-вторых, определение идентичности по гуидам может быть полезно только для интеропа. Для структурной идентичности нужно чтобы эквивалентность определялась самим рантаймом и только на основании описания типов.
VD>>Я слышал обратное. В прочем я слышал это о C#. D>Глядишь к 5 версии чего нибудь сделают.
Судя по реакции (полное молчание) Хейльсберга в шарпе точно ни фига не будет.
С другой стороны, если достаточная поддержка будет в рантайме, то для Немерле мы ее сделаем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Почитал дискуссию, не согласен со всеми
VD>Где-то я это уже видел... А в "Собачьем сердце".
VD>- Читал я эту переписку Кауткого с Троцким. VD>- И что же? VD>- А не согласен я! VD>- С кем же, простите за любопытство? VD>- Да, с обоими! VD>... VD>
Вообще-то, действительно не со всеми, а с обоими: IT и Tom.
Здравствуйте, adontz, Вы писали:
A>Почитал дискуссию, не согласен со всеми A>Суть задачи в том, чтобы сгенерировать DAL и немножечко бизнес логики (ну сколько получится). DAL в свою очередь, грубо говоря, состоит из SQL и C#. При этом почему-то ошибочно предполагается что C# или SQL могут хранить всю информацию, необходимую для генерации части на другом языке или даже могут это делать удобно. Враки это всё. Хуже того, сгенерировать DAL это пол-беды, надо уметь удобно переезжать со старой версии на новую, модифицируя схему БД.
A>DAL не просто можно, его обязательно нужно генерировать. Но не C# из SQL или SQL из C#. И то и другое надо генерировать из третьего, более приспособленного для хранения условий задачи, источника.м
Прочитал тему ( что отпуск с людьми делает )
Видел такие системы где тонны легаси "используют всю мощь xxx-sql", где в схеме данных черт ногу сломит, а описание входных/выходных xml-ек ... И к этому серверному хозяйству морды на с++/c#.
интересно детально рассмотреть свойства "третьего" языка. Инструментарий для работы с ним. Кто и с каким образованием будет на нем писать. Потому что подход "вся логика на шарпе" — он прост в плане управления и понятен программерам. У дэбэшников от него волосы встают дыбом но это не важно. Даже участвовал в обсуждении одного ресерча как раз на эту тему так что просьба развить тему. Сейчас все наперебой говорят про dsl, но никто не предлагает понятную методику работы с ним.
Здравствуйте, SleepyDrago, Вы писали:
SD>интересно детально рассмотреть свойства "третьего" языка. Инструментарий для работы с ним. Кто и с каким образованием будет на нем писать. Потому что подход "вся логика на шарпе" — он прост в плане управления и понятен программерам. У дэбэшников от него волосы встают дыбом но это не важно. Даже участвовал в обсуждении одного ресерча как раз на эту тему так что просьба развить тему. Сейчас все наперебой говорят про dsl, но никто не предлагает понятную методику работы с ним.
Лично я в качестве третьего языка использую файл в формате-который-не-имеет-значения и графический редактор к нему. Так же есть библиотека для выдирания настроек в виде C# объектов, её использует генератор.
P.S. На самом деле файл в XML, но это деталь реализации.
VD>Это немного не то. Точнее совсем не то. Во-первых, у интерфейсов нет структуры, так что их эквивалентности добиться не сложно. Главное чтобы совпадали сигнатуры и позиции методов.
Что значит нет структуры? В моем понимании то что описано в интерфейсе и есть его структура. VD>Во-вторых, определение идентичности по гуидам может быть полезно только для интеропа. Для структурной идентичности нужно чтобы эквивалентность определялась самим рантаймом и только на основании описания типов.
Можно этот гуид генерировать на основании описания.
Здравствуйте, adontz, Вы писали:
A>Вообще-то, действительно не со всеми, а с обоими: IT и Tom.
Ром, не обижайся, но твои рассуждения в этой теме не только по форме на шариковские похожи. Они и по сути тоже не ахти. На все твои утверждения с уверенностью можно сказать, что они не верны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Лично я в качестве третьего языка использую файл в формате-который-не-имеет-значения и графический редактор к нему. Так же есть библиотека для выдирания настроек в виде C# объектов, её использует генератор.
Ок я видел такие системы и участвовал в обсуждении.
Пункт первый. Разработчик визуального редактора повторял (дословно! с учетом перевода на рус) следующее "Дали бы еще месяц на его доработку..." Насколько знаю никто не дал
Пункт второй. Генератор для шарпа и плюсов в принципе понятен. Пишется на шарпе с antlr+-stringtemplate. На выходе определения сущностей и тп. Пишется как правило теми же кто и будет использовать. Вот с генераторами для xxx-sql не все так просто. Во первых люди которые "используют всю мощь" далеки от рутины программирования на шарпе — тут будут постоянные высокочастотные общения db-people с c#-people. Во вторых языки (я знаком только с оракловым вариантом так что не в курсе про мс) xxx-sql, они как бы это сказать — непростые для понимания неподготовленными людьми, а иметь монстра c#-db в одном флаконе завязанного на один высококритичный генератор ммм рискованное дело.
В третьих — как на этом языке-с-визуальным-редактором будет описываться бизнес логика (самое объемное и важное) ? Тут нужны пояснения.
зы. Чтобы не растекаться по древу ответы на первые два пункта можно пропустить тк это скорее кадровые проблемы.
ззы спасибо, хоть я сейчас далек от этого, но от ... лучше не зарекаться
Здравствуйте, VladD2, Вы писали:
VD>Ром, не обижайся, но твои рассуждения в этой теме не только по форме на шариковские похожи. Они и по сути тоже не ахти. На все твои утверждения с уверенностью можно сказать, что они не верны.
Влад, ну ты вместо аргументированного ответа решил задеть собеседника? Когда нечего сказать по существу, лучше вообще не писать.
Здравствуйте, dotneter, Вы писали:
D>Что значит нет структуры? В моем понимании то что описано в интерфейсе и есть его структура.
То и значит. Нет полей. Нет "структуры".
VD>>Во-вторых, определение идентичности по гуидам может быть полезно только для интеропа. Для структурной идентичности нужно чтобы эквивалентность определялась самим рантаймом и только на основании описания типов. D>Можно этот гуид генерировать на основании описания.
Крут ты! Я вот не знаю как такое сделать, да еще чтобы при этом не пересечься с гуидами сгенерированными другими средствами.
И, главное, не ясно зачем такие сложности? Ведь все что нужно — это стрктурная идентичность типов. Это еще в С было и в Лиспе. Так что "технологии" около 50 лет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, SleepyDrago, Вы писали:
SD>Пункт первый. Разработчик визуального редактора повторял (дословно! с учетом перевода на рус) следующее "Дали бы еще месяц на его доработку..." Насколько знаю никто не дал
О, это не проблема. Редактор очень простой. Первую версию я написал за неделю и до сих пор ей пользуюсь, даже и не думая о переписывании
SD>Пункт второй. Генератор для шарпа и плюсов в принципе понятен. Пишется на шарпе с antlr+-stringtemplate. На выходе определения сущностей и тп. Пишется как правило теми же кто и будет использовать.
Нет. Генератор для шарпа пишется на hypertext preprocessor.
SD>Вот с генераторами для xxx-sql не все так просто. Во-первых, люди которые "используют всю мощь" далеки от рутины программирования на шарпе — тут будут постоянные высокочастотные общения db-people с c#-people. Во-вторых, языки (я знаком только с оракловым вариантом так что не в курсе про мс) xxx-sql, они как бы это сказать — непростые для понимания неподготовленными людьми, а иметь монстра c#-db в одном флаконе завязанного на один высококритичный генератор ммм рискованное дело. В третьих — как на этом языке-с-визуальным-редактором будет описываться бизнес логика (самое объемное и важное) ? Тут нужны пояснения.
Нет. Редактор редактирует только модель. Генератор существует совсем отдельно и представляет собой что-то вроде PHP/ASP. В данный момент я его встраиваю в VS. Для C# вывод записывается в файл, для SQL вывод исполняется на сервере БД (ну и записывается в файл, заодно). То есть db-people вполне могут сгенерировать всё что захотят, или, для какой-то конкретной сущности, вообще всё написать руками.
Здравствуйте, adontz, Вы писали:
A>Влад, ну ты вместо аргументированного ответа решил задеть собеседника? Когда нечего сказать по существу, лучше вообще не писать.
Ром, аргументированный ответ можно дать только на аргументированное утверждение. А ты всего лишь декларировал некоторые постулаты которые попросту не верны.
Взять хотя бы утверждение "SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя".
1. В РСБУД и в SQL вообще нет объектов. Стало быть разговор о их возврате — это ээ... ну, сам придумай как это по мягче назвать, в общем.
2. Утверждение о нетипизированности запросов стоило бы обосновать. Оно явно не верно, но без твоего обоснования я должен тратить свои силы на обоснование очевидного факта.
3. Запрос, в РСУБД, всегда возвращает список записей (они не даром так называются, запись это кортеж с именованными полями). Единичное (скалярное) значение не более чем частный случай — список состоящий из одной записи которая в свою очередь состоит из одного элемента (поля).
Если запрос делается над таблицами (которые тоже являются списками записей) типы полей которых, вывести тип возвращаемого значения не проблема.
Теперь о причинах по которым тебе тяжело будет объяснить почему ты не прав.
Дело в том, что ты исходишь из узкого и не верного трактования действительности. Ты смотришь на доступ к данным через призму ООП-теории. Этот взгляд не может привести к пониманию обсуждаемого в данной теме. Отсюда все разговоры о выборе объектов из базы. О каких то там связях частей объектов и т.п.
Так что первое что нужно понять для понимания этой темы — в БД нет объектов. И мы просто предлагаем вместо работы с объектами в БД, работать с данными вынимаемыми из БД и размещаемыми структурах удобных для обработки в прикладном языке программирования.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Влад, ну ты вместо аргументированного ответа решил задеть собеседника? Когда нечего сказать по существу, лучше вообще не писать.
Ром. Ну, ты же пишешь чёрт знает что и даже не думаешь об обосновании своих утверждений?
Пойми, такой уровень разговора не располагает к аргументированному ответу. Первое что захотелось сделать в ответ на твое сообщение это отквотить его и написать "чушь" к каждому утверждению. Я сдержался и ответил спокойно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, SleepyDrago, Вы писали:
SD>>Пункт первый. Разработчик визуального редактора повторял (дословно! с учетом перевода на рус) следующее "Дали бы еще месяц на его доработку..." Насколько знаю никто не дал
A>О, это не проблема. Редактор очень простой. Первую версию я написал за неделю и до сих пор ей пользуюсь, даже и не думая о переписывании
Именно так и было — первые месяцы. Потом к использованию редактором подключили спецов предметной области Я участвовал в нескольких разборах того что им не нравилось, так что могу себе представить глубину кроличьей норы
SD>>Пункт второй. Генератор для шарпа и плюсов в принципе понятен. Пишется на шарпе с antlr+-stringtemplate. На выходе определения сущностей и тп. Пишется как правило теми же кто и будет использовать.
A>Нет. Генератор для шарпа пишется на hypertext preprocessor.
Не важно. Его пишут programmers.
SD>> как на этом языке-с-визуальным-редактором будет описываться бизнес логика (самое объемное и важное) ?
A>Нет. Редактор редактирует только модель. Генератор существует совсем отдельно ...
именно это и было сделано. Редактор ооп модели. Вам же в теме показывали листинги "сложных запросов" Чем вы предлагаете их заменить? Это в чистом виде бизнес логика. Причем в терминах, к которым ооп имеет отдаленное отношение Плюс протокол общения клиента и сервера. Те самые result set'ы. Это ж отдельная копилка багов на обоих сторонах. В процессе эволюции там происходят такие мутации что Я даже видел попытку сделать несколько языков. Один для протокола другой для логики и тп.
В общем есть мнение что от количества сгенерированных сущностей размер работы не уменьшается. Вот если для сущности генерировать настраиваемую на каждом этапе цепочку (визуальный редактор — протокол обмена с сервером данными — тупая бизнес логика — структура хранения) это было бы интересно. Языки описания этого всего в один не-скажу-какого формата файл явно не лезут для типичных систем. Для простоты можно ui отбросить тк это все равно трудоемкая часть и там прорыва в ближайшее время можно не ждать. Обмен данными с сервером и их обработка на сервере — это то о чем здесь ломают копья (и не в первый раз).
Здравствуйте, VladD2, Вы писали:
VD>То и значит. Нет полей. Нет "структуры".
Тоесть для интерфейса понятие структурной эквивалентности не применимо?
И
interface IValue
{
int Value {get;set;}
}
class A: IValue
{
public int Value {get;set;}
}
interface IValue2
{
int Value{get;set;}
}
public void Test(IValue2 value);
Test(new A())
нельзя назвать эквивалентностью интерфейсов?
Можно тогда какой нибудь пример применения этой самой структурной эквивалентности?
VD>Крут ты! Я вот не знаю как такое сделать, да еще чтобы при этом не пересечься с гуидами сгенерированными другими средствами.
Ну а чего, для IValue берем строку вида "int,Value" и генерим по ней Guid, дешево и сердито.
Здравствуйте, SleepyDrago, Вы писали:
A>>Нет. Редактор редактирует только модель. Генератор существует совсем отдельно ... SD>именно это и было сделано. Редактор ооп модели. Вам же в теме показывали листинги "сложных запросов" Чем вы предлагаете их заменить?
Я задачу "генерировать всё" вообще никогда перед собой не ставил. Нет и не может быть удобного универсального генератора для всего. Я ставил задачу сгенерировать 90%, и позволить остальные 10% писать руками так, чтобы они органично вливались в сгенерированный код.
Скажем для запросов, я хочу перейти на Linq, а не писать sQL код, потому что это увеличит типобезопасность. Но даже так, основной выигрыш налицо — руки писать надо гораздо меньше.
SD>Обмен данными с сервером и их обработка на сервере — это то о чем здесь ломают копья (и не в первый раз).
Не совсем понял, проблема в том что передавать или в том как?
)
Насколько знаю никто не дал 
Я даже видел попытку сделать несколько языков. Один для протокола другой для логики и тп.