Несомненно.
Tom>Я кстате так и не понял почему анонимый тип в C# нельзя явно обьявлять. Как в других человеческих языках. (((
Аналог анонмных типов в ФЯ — это записи. Запись — это кортеж с именованными полями. Проблема в том, что кортежи и записи в ФЯ имеют так называемую структурную идентичность. Это значит, что два объекта сравнимы если у них одинаковый набор полей и у всех полей совместимые (соответственно) поля.
В дотнете структурная совместимость не поддерживается. Посему типы объеявленные в разных сборках являюся разными типами. Да и имена у них обязаны быть обязательно, а типы с разными именами тоже разные (даже если структурно они эквивалентны).
В общем, не поддерживает дотнет эту фичу.
Во времена когда шла работа над 3.5-ым фрэймворком Хейльсберг говорил, что им, мол, не дают им бедным менять рантайм. А то бы они давно сделали экспорт анонимных типов... Вот только в 4-ом дотнете, где будет новый рантайм, все равно ничего для поддержки структурной идентичности сделано не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
IT>>Обезъяна с гранатой не знает что с ней делать. А если гранатой умело воспользоваться, то можно легко изничтожить тонны тупого копипейстного кода. И поддержка такого кода только выигрывает. Tom>Игорь, но ведь ьты предлагаешь писать больше кода. Как минимум классы resultset-ов.
Имеем DDL:
CREATE TABLE Person
(
PersonID int NOT NULL IDENTITY(1,1) CONSTRAINT PK_Person PRIMARY KEY CLUSTERED,
FirstName nvarchar(50) NOT NULL,
LastName nvarchar(50) NOT NULL,
MiddleName nvarchar(50) NULL,
Gender char(1) NOT NULL CONSTRAINT CK_Person_Gender CHECK (Gender in ('M', 'F', 'U', 'O'))
)
ON [PRIMARY]
Засекаем время, копипейстим, переформатируем, получаем:
public class Person
{
public int PersonID;
public string FirstName;
public string LastName;
public string MiddleName;
public char Gender;
}
На всё ушло меньше одной минуты. Можно вообще ничего не писать, есть генератор, который сделает тоже самое. Затем сгенерированный файл вставляется в проект и далее поддерживается вручную. Кстати, многие, кто использует linq2sql именно так и делают, т.е. классы генерируются один раз вначале, из них вычищается весь мусор и далее всё поддерживается ручками.
Tom>Напела мне жизнь. Допустим в линке есть некоторая поддержва в явном виде выборки данных. и нету поддержки UPDADE/DELETE/INSERT. В выборке данных есть поддержка всего процентов наверное 10-20 от всей мощи TSQL. Вопрос, нахрена козе баян? И что делать с действительно сложными запросами, которых у нас в огромном количестве. Да и смысла подменять один язык TSQL другим linq я не вижу. Тем более, что ты упорно игнорируешь тот факт что он мёртв.
Linq2SQL может быть и мёртв, но сама технология Linq 2 anything else вполне себе ничего. А это значит, что рано или поздно появятся другие вполне вменяемые реализации. Об этом ещё рано говорить, но сейчас я занимаюсь поддержкой linq в BLToolkit и большинство вещей, о которых ты говоришь там будут устранены изначально. На самом деле, глядя на реализацию, видно, что команда linq2sql во многих местах схалтурила и некоторые вещи можно было бы сделать гораздо более эффективно. Да и не надо было им умничать со стейтом, нужно было делать тупой генератор DML, чем я сейчас и занимаюсь.
Если нам не помогут, то мы тоже никого не пощадим.
IT>Linq2SQL может быть и мёртв, но сама технология Linq 2 anything else вполне себе ничего. А это значит, что рано или поздно появятся другие вполне вменяемые реализации. Об этом ещё рано говорить, но сейчас я занимаюсь поддержкой linq в BLToolkit и большинство вещей, о которых ты говоришь там будут устранены изначально. На самом деле, глядя на реализацию, видно, что команда linq2sql во многих местах схалтурила и некоторые вещи можно было бы сделать гораздо более эффективно. Да и не надо было им умничать со стейтом, нужно было делать тупой генератор DML, чем я сейчас и занимаюсь.
Это уже больше похоже на что то что можно будет применять. Интересно сколько это всё займёт кода.
G>Наверное потому что он будет неанонимным
Ответ неправильный. НЕ анонимный тип имеет имя. По этому имени его можно использовать.
Анонимный тип имени не имеет, но имеет тип, по которому его можно использовать.
Например как то так:
Здравствуйте, Tom, Вы писали:
IT>>Ну так MS и в твой генератор ресурсы вкладывать не будет. Tom>как это не будет если они его написали T4 используется в самой студии и для того же линка.
Дык linq2sql они тоже написали, где гарантия, что они не похоронят и T4?
IT>>Что касается спроков, то здесь у BLToolkit конкурентов нет. Вообще. Tom>От стор мы отказываемся, для On Demand систем это зло которое затрудняет обновление системы без downtime-а
А как же 1000 хранимок в легаси-коде?
Tom>Весь разговор сводится к тому что BLToolkit это хорошо, но на мои аргументы я так ответа твоего не услышал.
Я вообще говорю про BLToolkit только как пример того, что что-то можно сделать по-другому. Никого его заставлять использовать я не собираюсь.
Tom>Ещё раз повторю: Tom>При использовании BLToolkit-а приходится:
Но если очень хочется поговорить о BLToolkit, то давай поговорим. Начнём с того, что BLToolkit разрабатывался не только как набор готовых к использованию компонент, но и как библиотека для построения собственных фреймворков, поэтому большинство из нижеперечисленного решается так или иначе.
Tom>1. Писать руками классы акцэсоров/resultset-ов. Что в свою очередь:
Классы аксессоров пишутся на уровне декларации, код аксессоров писать не нужно, только объявление метода.
Tom>1.1 Затрудняет поддержку. Так как если селект возвращает новое поле, или не возвращает поля вообще то во время компиляции ты об этом никогда не узнаешь.
У вас селекты и бизнес-логику пишут разные люди? Или всё же девелопер добавляет поле в селект, добавляет его в entity, проверяет что его затея удалась и только потом отчитывается о проделанной работе?
К тому же для проверки сломалось/не сломалось есть такая штука как юнит-тесты, лучше них пока в этом плане ничего не придумано. С другой стороны сама идея иметь на каждый отдельный запрос новый класс мне кажется, извини, слегка бредовой, особенно, если запрос возращает на одно поле больше или меньше.
Tom>1.2 делает невозможным переход на BLToolkit для Legacy прилоджений. Допустим у нас 1000 хранимок возвращабщих resultset. Никто не будет руками писать и поддерживать эту 1000 классов.
Не классов, а методов. Не хочешь писать, не пиши, сгенерируй аксессоры один раз и дальше поддерживай. Можно опять же заиспользовать генератор линка, а потом вычистить из него всё лишнее.
Tom>2 Поощеряет написание TSQL в коде. Что усложняет поддержку. А именно: Tom>2.1 Проверить синтаксис TSQL можно только в runtime.
BLToolkit умеет очень многое, и ещё большему его можно обучить. В частности читать SQL из внешних файлов, которые ты как-то там будешь верифицировать — это вообще не проблема. Более того мы умеем читать разный SQL для разных провайдеров, что позволяет создавать приложения, работающие с разными БД.
Tom>2.2 Делает невозможным использовать средства рефакторинга/анализа TSQL кода, такие как VSTS Database Edition GDR и прочие.
Читай выше.
Tom>2.3 Делает невозможным валидацию кода в compile time средствами, которые являются аналогом Fx Cop но для TSQL. (фактически анализ кода)
Без понятия что это такое, но если это опять имеет отношение к внешнему SQL, то с этим проблем нет.
Tom>Если интересно продолжать то хотелось бы аргументированно и с примерами.
Примерами чего?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
G>>Наверное потому что он будет неанонимным Tom>Ответ неправильный. НЕ анонимный тип имеет имя. По этому имени его можно использовать. Tom>Анонимный тип имени не имеет, но имеет тип, по которому его можно использовать.
Тип и есть тип. В случае анонимного типа мы не можем написать его в программе, потому что не знаем его имени, если знаем имя, то тип перестает быть анонимным.
Tom>Например как то так: Tom>
Tom>{string, int} t = new {Name="", 123}
Tom>
Полу-именнованный кортеж чтоли? Такое хоть где-то работает?
{string, int} t1 = new {FirstName="", 123}
{string, int} t2 = new {LastName="", 123}
t1.GetType() == t2.GetType() //? как оно вообще работает?
//если у нас функцияvoid func({string, int} p) //Она вообще что принимает?
Tom>Плюс от такого подхода очевиден?
Нет, это бредятина какая-то.
Здравствуйте, Tom, Вы писали:
Tom>ну вот поростой и типичный вариант
От такого нужно избавляться в первую очередь.
Tom>C# никак не предназначен на сегодняшний день для манипуляции данными. Тем боллее, что серверов БД существует великое множество. И у каждого свой SQL диалект.
Если ты называешь манипуляцией данными то, что ты привёл выше, то это скорее бизнес логика, написанная на TSQL. Это нужно устранять в первую очередь. SQL должен заниматься исключительно тем, для чего он создавался — манипуляцией данными, т.е. исключительно запросами вида SELECT/INSERT/UPDATE/DELETE.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>Вот что исходники откроют я верю. Как раз из за проблем поддержки. Что бы спихнуть её на комьюнити. Но без открытия исходников компилятора нормально линк развивать не получится.
Компилятор то тут при чём?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
VD>>Вопрос был: сгенерирует ли твой генератор один тип для этих двух запросов, или два разных? Tom>Генератор сгенерирует скорее метод возвращающий анонимный тип.
Анонимный тип нельзя возвращать из метода.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Полу-именнованный кортеж чтоли? Такое хоть где-то работает?
Да. Во многих ФЯ. В ОКамле, например. Называется запись (record).
Но в ФЯ типы кортежей совместимы по структуре. Это называется структурной идентичностью.
Если объявить две записи с одним набором полей (и типов у каждого поля), то их объекты будут иметь один тип и их можно будет использовать друг вместо друга. Так же их можно будет сравнивать и копировать.
Но такая фича не поддерживается в дотнете. По этому даже ФЯ реализованные на дотнете не поддерживают записей (по крайней мере в полной мере).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
IT>Если ты называешь манипуляцией данными то, что ты привёл выше, то это скорее бизнес логика, написанная на TSQL. Это нужно устранять в первую очередь. SQL должен заниматься исключительно тем, для чего он создавался — манипуляцией данными, т.е. исключительно запросами вида SELECT/INSERT/UPDATE/DELETE.
IT>Реализация самого провайдера? А какая разница?
Ну как же, если это предпологаемое решения для работы с данными — и оно написано руками то поддерживать его придётся.
Вот мне и интересно, насколько игра стоит свеч.
Здравствуйте, Tom, Вы писали:
Tom>Ну тогда тебе в ORM лагерь.
Это смотря какой ORM? ORM'ы бывают разные. Бывают heavy ORM, бывают lightweight ORM. BLToolkit относится ко второй категории.
Что же касается бизнес логики на TSQL, которую ты здесь привёл, то это одно из двух: либо пережиток старого, либо дурь. Надеюсь первое. Разумного оправдания такой практике сегодня нет.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
IT>>Реализация самого провайдера? А какая разница? Tom>Ну как же, если это предпологаемое решения для работы с данными — и оно написано руками то поддерживать его придётся. Tom>Вот мне и интересно, насколько игра стоит свеч.
Я не пойму о чём ты. О коде, который я сейчас пишу или о коде, который ты потом будешь писать?
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
T4 используется в самой студии и для того же линка.
А какая разница?
