LLBLGen, по аналогичному опыту работы на новом месте, -- это форменный ахтунг. Я слабо себе представляю даже, как его можно использовать.

Дальше, возможно, будет некая доля субъективизма, но от нее никуда не деться.

Во-первых, сама идея автоматической генерации классов "мне странна". Если с этим смириться, то на сцену выходит дизайнер. Он какой-то очень замороченный: поднимает все метаданные из БД и генерирует тучу кода по поводу загрузки объектов через все relation'ы подряд. Все это нафиг никому не нужно, а код засоряется.

Более того, код засоряется перегрузками вида GetCustomers_(), GetCustomers__(), GetCustomers___() и т.д.

Совершенно невменяемая работа с фильтрами: ручная возня с IPredicate и прочими IExpression как-то не впечатляет.

Так и не удалось нормально научить его работать с table-per-hierarchy реализацией наследования.

Полиморфные запросы не работают.

Ленивая загрузка если и работает, то очень странно.

Список можно продолжать, но только как дискуссию а-ля "а как там-то и сям-то делается такая вот вещь".

Однако же если LLBLGen уже используют, то заставить от него отказаться будет очень и очень непросто.

Saпочему?
Потому что генератор, если он будет простой, то не сможет справиться с моими задумками. Я, например, не хочу иметь класс, один к одному дублирующий структуру таблицы; какие-то поля мне не нужны, а какие-то я хочу агрегировать в отдельный класс. Плюс еще хочу заполучить иерархию классов в какой-нибудь замороченной структуре.

А тот генератор, который с этим всем справится, уже не будет простым либо никогда не будет написан, либо будет таким сложным, что я быстрее врукопашную все напишу, чем разберусь в нем.

К тому же (камень в город LLBLGen'а) его *.lgp файлы бинарные, так что ни о какой коллективной работе речи не идет.

Viktor BartelПо третьему пункту может быть есть небольшая возможность, т.к. Я попал в период реструктуризации департамента разработки ПО, народ сваливает и новые люди приходят. Но что бы гнуть мою линию мне нужны неоспоримые доводы для начальства, именно по-этому я и обратился за помощью на данный форум.
Ну покажите им, как одна и та же задача решается средствами BLT и LLBLGen'а.

зы2Нахлобуч:
- предикаты пишутся спокойно без интерфейсов и без ручной возни, см. раздел предикаты для .net 2.0

Кроме этого ужаса:
ничего не нашел. Покажешь, куда смотреть?
зы
- кроме того чтобы писать класс руками, ещё быстрее будет дописать то что тебе нагенерит llblgen, чудое он не затрет.
Писать где? Править шаблоны, что ли? Так егойный шаблон не является валидным исходником на C#, что автоматически отменяет всякие интеллисенсы и решарперы. Я так писать не намерен. partial-классы, если только.
зы
- не нравится куча непонятного кода, можно выбрать DataAdapter :)
Это который противоположность SelfServicing?
зы
- куча методов с подчеркиваниями - потому что либо дофига одинаковых имен у тебя в базе, либо надо отключать все ненужное. Пол часа возни в дизайнере, зато потом все чисто и аккуратно до конца жизни.
См. скрин. Захватывающе, не правда ли?
зы
- ленивая загрузка у меня никогда не работала странно. В чем странность у тебя?
Нервов не хватило разобраться с той ромашкой разобраться, что она мне устраивала. "Буду работать - не буду работать - может быть, не буду".
зы
- в релейшенах есть смысл, поймешь когда надо будет делать сложную фильтрацию. Конечно это не так красиво как в том же dlinq, например, но они обещают порт под dlinq (если уже не сделали), так что можно будет писать коротко и читаемо.
AFAIK, ничего такого не сделано еще. К тому же, еще не все на 3.0+ перешли.
зы
- из хранимых процедур можно вернуть не только датасет или дататаблицу, но и объект. Смотри шейпинг.
Это все очень приятно, но на общем фоне как-то бледненько.

зы
1) collection.GetMulti((TableFields.Foo == "a" & TableFields.Bar==1) | Table2Fields.Foo="b"), вообще-то все написано в хелпе :)
SelfServicing фтопку. А вот то, что ты написал -- это жесткий хардкод. В рантайме такое не соберешь.
зы
2) открой сгенеренный файл, найдешь секцию че-то вроде # custom code here. Читай хелп, раздел как расширять класс своим кодом.
Начитал три варианта, из которых приемлемый только partial classes.
зы
4) хотелось бы увидеть скриншот диаграммы этой части таблиц, думаю все будет понятней. В любом случае show/hide members/relations рулит
Это сущность "Валюта", на которую завязана куча таблиц.