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


_>Хм, что-то не очень понятно (видимо потому что я с Linq не работаю), в особенности чем являются различных идентификаторы не из таблиц (которые не m. и f.). Или может вместо объяснения ты просто покажешь какой sql генерируется из этого запроса? )

Что-то вроде такого:

// FROM Message ,
from m in db.Messages

// JOIN AllowedForumsView(@accountID) f ON m.ForumID = f.ID
join f in db.AllowedForumsView(Account.ID) on m.ForumID equals f.ID

// WHERE
where

//      m.ID IN (здесь список целочисленных констант)
    ids.Contains(m.ID) &&

//      EXISTS (SELECT * FROM BlogMessages.All bm WHERE m.BlogID = bm.BlogID AND bm.BolgID != @blogID)
    m.BlogMessages.All(bm => bm.BlogID != BlogService.Cache.GetBlogID(db, id))

// ORDER BY m.Subject
orderby
    m.Subject

// SELECT m.ID, m.Subject;
select
    m.ID + ", " + m.Subject;

_>Ну да, DAL — это правильное решение для сложных проектов и особенно рассчитанных на работу с разными СУБД.

DAL — это анахронизм. Тем более при работе с разными СУБД.

_>В базе null конечно же может быть и для работы с ним там в библиотечке есть все необходимые средства (и соответствующий предикат условий и проверка результатов запросов). Автору даже предлагали сделать возврат значений для не "not null" колонок через std::optional (аналог Nullable<T> из C#), но он предпочёл обойтись проверочной функций (видимо из соображений эффективности).

Понятно. Т.е. без широко обсуждаемых кастылей не обошлось.