Сразу признаюсь, что не имею хорошего опыта работы с этой штукой и пользовался ранее nhibernate. При использовании данного инструментария генерируется контекст данных и набор классов, отображающих таблицы. Для отображения на бизнес объекты дабы не привязываться к таблицам напрашивается отображение генерируемых объектов на сущности внутри репозитариев. Однако при наличии связей между сущностями эта задача становится неоправданно объёмной. Кто как пользуется этим инструментом?

Здравствуйте, Аноним, Вы писали:
А>Кто как пользуется этим инструментом?

Насколько я понял из непродолжительного ознакомления с LinqToSql, он изначально расчитан на то, что таблицы базы данных будут прямиком отображаться на классы в клиентском коде.
Т.е. идеология как раз такова чтобы именно ПРИВЯЗЫВАТЬСЯ к таблицам. И бизнес-логику строить от данных, а не наоборот.
Другой подход, в принципе, возможен, но это уже ИМХО будет сродни забиванию гвоздей плоскогубцами: можно, но инструмент расчитан на другое применение.

Здравствуйте, stomsky, Вы писали:

S>Здравствуйте, Аноним, Вы писали:
А>>Кто как пользуется этим инструментом?

S>Насколько я понял из непродолжительного ознакомления с LinqToSql, он изначально расчитан на то, что таблицы базы данных будут прямиком отображаться на классы в клиентском коде.
S>Т.е. идеология как раз такова чтобы именно ПРИВЯЗЫВАТЬСЯ к таблицам. И бизнес-логику строить от данных, а не наоборот.
S>Другой подход, в принципе, возможен, но это уже ИМХО будет сродни забиванию гвоздей плоскогубцами: можно, но инструмент расчитан на другое применение.

Привязываться к автогенерируемым по классам в бизнес логике по моему как то слишком круто .

Здравствуйте, Аноним, Вы писали:

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

L2S ИМХО хорош в двух случаях:
1. Бизнеслогика очень проста или по каким-то другим причинам очень хорошо ложится на базу, мапинг "таблица — класс" отлично подходит и нечего огороды городить.
2. Бизнеслогика очень сложна или по каким-то другим причинам вообще никак не ложится на базу и при работе с БД проще "руками" всё разложить по таблицам чем строить многомудрые мапинги в L2E.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Здравствуйте, Аноним, Вы писали:

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

YKU>L2S ИМХО хорош в двух случаях:
YKU>1. Бизнеслогика очень проста или по каким-то другим причинам очень хорошо ложится на базу, мапинг "таблица — класс" отлично подходит и нечего огороды городить.
Тут ещё ограничение на anemic model возникает...

Здравствуйте, Аноним, Вы писали:
А>Привязываться к автогенерируемым по классам в бизнес логике по моему как то слишком круто .
А что в этом такого страшного?

Здравствуйте, stomsky, Вы писали:

S>Здравствуйте, Аноним, Вы писали:
А>>Привязываться к автогенерируемым по классам в бизнес логике по моему как то слишком круто .
S>А что в этом такого страшного?
— Я предпочитаю POCO, а в автогенерируемые классы движок linq2sql пихает кучу барахла
— Как следствие первого пункта, Domain вынужден ссылаться на DAL

Здравствуйте, Аноним, Вы писали:
А>- Я предпочитаю POCO, а в автогенерируемые классы движок linq2sql пихает кучу барахла
А>- Как следствие первого пункта, Domain вынужден ссылаться на DAL
Тогда, подозреваю, придется DTO делать... Что выглядит действительно кривовато...
Слушай, может ну его нафиг, этот LinqToSql, а?
Возьми что-нибудь другое. Я вот BLToolkit'ом в нескольких своих программках пользовался: милое дело! Он и Linq поддерживает!

Здравствуйте, stomsky, Вы писали:

S>Здравствуйте, Аноним, Вы писали:
А>>- Я предпочитаю POCO, а в автогенерируемые классы движок linq2sql пихает кучу барахла
А>>- Как следствие первого пункта, Domain вынужден ссылаться на DAL
S>Тогда, подозреваю, придется DTO делать... Что выглядит действительно кривовато...
S>Слушай, может ну его нафиг, этот LinqToSql, а?
S>Возьми что-нибудь другое. Я вот BLToolkit'ом в нескольких своих программках пользовался: милое дело! Он и Linq поддерживает!
Я начал с того, что указал, что обычно пользуюсь nhibernate

Здравствуйте, Аноним, Вы писали:
А>Я начал с того, что указал, что обычно пользуюсь nhibernate
Да я заметил. Но ведь не с проста же возник интерес к LinqToSql, верно?
Хотя, если интерес был чисто спортивный, тогда "звиняй, хлопэц"!

Здравствуйте, stomsky, Вы писали:

S>Здравствуйте, Аноним, Вы писали:
А>>Я начал с того, что указал, что обычно пользуюсь nhibernate
S>Да я заметил. Но ведь не с проста же возник интерес к LinqToSql, верно?
S>Хотя, если интерес был чисто спортивный, тогда "звиняй, хлопэц"!
Возникло подозрения что я что-то не догнал и с linq2sql всё лучше, чем мне показалось. Судя по всему всё плохо

Здравствуйте, Аноним, Вы писали:
А>Возникло подозрения что я что-то не догнал и с linq2sql всё лучше, чем мне показалось. Судя по всему всё плохо
Да нет. Народ как-то использует его в многозвенках. Просто мне как-то в основном двух звеньев хватает...

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>L2S ИМХО хорош в двух случаях:
YKU>1. Бизнеслогика очень проста или по каким-то другим причинам очень хорошо ложится на базу, мапинг "таблица — класс" отлично подходит и нечего огороды городить.
YKU>2. Бизнеслогика очень сложна или по каким-то другим причинам вообще никак не ложится на базу и при работе с БД проще "руками" всё разложить по таблицам чем строить многомудрые мапинги в L2E.

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