Появилось ли BLToolkit, что-то подобное Include EF. Какими решениями Вы пользуетесь. Рассматривается вариант перехода с EF на BLToolkit, но у нас много ассоциаций и начальство может не дать добро из за этой проблемы.

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

А>Появилось ли BLToolkit, что-то подобное Include EF. Какими решениями Вы пользуетесь. Рассматривается вариант перехода с EF на BLToolkit, но у нас много ассоциаций и начальство может не дать добро из за этой проблемы.

Пока только в планах.

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

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

А>>Появилось ли BLToolkit, что-то подобное Include EF. Какими решениями Вы пользуетесь. Рассматривается вариант перехода с EF на BLToolkit, но у нас много ассоциаций и начальство может не дать добро из за этой проблемы.

IT>Пока только в планах.

Неужели за всю многолетнюю историю никому не надо было? Я тогда не понимаю в каких ситуациях используют ассоциации?
А есть ли какие-то Best Practice по этому вопросу? Какие есть альтернативные пути? А то как-то в рукопашную идти не очень хочется. Очень хочется начать использовать, а тут такая засада.
У меня возник вопрос по поводу LINQ и DataAccessor. Правильно ли я понимаю, что при наличии LINQ, создавать DataAccessor уже недо? CRUD есть и на LINQ.

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

А>Неужели за всю многолетнюю историю никому не надо было? Я тогда не понимаю в каких ситуациях используют ассоциации?

В ситуациях где обычно используется JOIN — http://www.bltoolkit.net/Doc.LinqAssociations.ashx.

А>А есть ли какие-то Best Practice по этому вопросу? Какие есть альтернативные пути? А то как-то в рукопашную идти не очень хочется. Очень хочется начать использовать, а тут такая засада.

Это глубоко философский вопрос Неявная подгрузка данных с одной стороны, конечно, облегчает жизнь. Но с другой приводит к потере контроля над тем что происходит. Хотя вариант с Include вроде более менее подконтролен, т.к. указывает явно что нужно подгружать.

А>У меня возник вопрос по поводу LINQ и DataAccessor. Правильно ли я понимаю, что при наличии LINQ, создавать DataAccessor уже недо? CRUD есть и на LINQ.

Правильно.

IT>Это глубоко философский вопрос Неявная подгрузка данных с одной стороны, конечно, облегчает жизнь. Но с другой приводит к потере контроля над тем что происходит.
Мне кажется вы не много не понимаете, большинство пользователей именно этого и хочет. Они хотят что бы объект загрузился при минимальном наборе команд, тонкости реализации им неинтересны. Кого потом не будет устраивать быстродействие, будет писать все ручками.

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

IT>>Это глубоко философский вопрос Неявная подгрузка данных с одной стороны, конечно, облегчает жизнь. Но с другой приводит к потере контроля над тем что происходит.
D>Мне кажется вы не много не понимаете, большинство пользователей именно этого и хочет.

Дело не в непонимании. Дело в поступиться принципами. Хотя, если такую фичу сделать отключенной по умолчанию и её нужно будет явно включать, то тогда пользователь сам себе Злобный Буратина.

Здравствуйте, IT, Вы писали:
IT>Это глубоко философский вопрос Неявная подгрузка данных с одной стороны, конечно, облегчает жизнь.
Неявная это в смысле ленивая? Она то конечно зло, но с инклюдом никак не связана.
Вот так же будет работать?

var data = (from p in db.Product
select new
{
    Product = p
    p.Category,
    
}).First();
var p = data.Product;
p.Category = data.Category;

Инклюд же просто сократит это все до одной строки.

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

D>Инклюд же просто сократит это все до одной строки.

Инклюды бывают разные. Например, можно подгружать коллекцию. В этом случае, например, L2S создаёт один расширенный запрос для двух таблиц и пока это чревато лишь дополнительным объъёмом подгружаемых данных. Но если инлюдом заданы два списка, то для первого будет создан расширенный запрос, а вот для второго уже будут дёргаться множество подзапросов.

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

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

D>>Инклюд же просто сократит это все до одной строки.

IT>Инклюды бывают разные. Например, можно подгружать коллекцию. В этом случае, например, L2S создаёт один расширенный запрос для двух таблиц и пока это чревато лишь дополнительным объъёмом подгружаемых данных. Но если инлюдом заданы два списка, то для первого будет создан расширенный запрос, а вот для второго уже будут дёргаться множество подзапросов.
Вроде тут все просто, либо сделать не как в l2s, либо кидать исключение что данный сценарий не поддерживается.

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

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

А>>Неужели за всю многолетнюю историю никому не надо было? Я тогда не понимаю в каких ситуациях используют ассоциации?

IT>В ситуациях где обычно используется JOIN — http://www.bltoolkit.net/Doc.LinqAssociations.ashx.

А до LINQ ассоциаций не было?

А>>А есть ли какие-то Best Practice по этому вопросу? Какие есть альтернативные пути? А то как-то в рукопашную идти не очень хочется. Очень хочется начать использовать, а тут такая засада.

IT>Это глубоко философский вопрос Неявная подгрузка данных с одной стороны, конечно, облегчает жизнь. Но с другой приводит к потере контроля над тем что происходит. Хотя вариант с Include вроде более менее подконтролен, т.к. указывает явно что нужно подгружать.

Вариант с Include приемлемый поскольку он контролируемый и подойдёт в большинстве случаев (понимая как он работает). Например для разного рода UI этого достаточно. Если же у меня есть сложная логика с большим объёмом данных, то и работать я буду по другому.
Попробую для себя поменять Т4, что бы добавить copy constructor, тогда можно будет использовать следующую конструкцию.

var data = (from p in db.Product
select new Product(p) 
       {
           Category = p.Category    
       }).First();

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

А>Вариант с Include приемлемый поскольку он контролируемый и подойдёт в большинстве случаев (понимая как он работает).

Он лишь чуть более более контролируемый. Как я уже писал, достаточно сделать Include на две коллекции, как мы тут же получим подзапросы на одну из коллекций, причём незаметно по-тихому.

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

А>Появилось ли BLToolkit, что-то подобное Include EF. Какими решениями Вы пользуетесь. Рассматривается вариант перехода с EF на BLToolkit, но у нас много ассоциаций и начальство может не дать добро из за этой проблемы.

У нас получилось так, для постепенного перехода оставили модель EF и клали выборку BLT в эту модель. Разложение по ассоциациям делали так: использовали DataAccessor и MapResultSet.

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

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

А>>Появилось ли BLToolkit, что-то подобное Include EF. Какими решениями Вы пользуетесь. Рассматривается вариант перехода с EF на BLToolkit, но у нас много ассоциаций и начальство может не дать добро из за этой проблемы.

SG>У нас получилось так, для постепенного перехода оставили модель EF и клали выборку BLT в эту модель. Разложение по ассоциациям делали так: использовали DataAccessor и MapResultSet.

А можно по подробней с примером, а то я ничего не понял

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

А>>У меня возник вопрос по поводу LINQ и DataAccessor. Правильно ли я понимаю, что при наличии LINQ, создавать DataAccessor уже недо? CRUD есть и на LINQ.

IT>Правильно.

неправильно (в части DataAccessor)
имхо одно другого не отменяет, и у дата аксессоров есть как минимум приятная возможность кэшировать результаты, а уж везде писать db.MyObject.Where(_ => _.Id == id).FirstOrDefault() так это ваще мутотень

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

ili>а уж везде писать db.MyObject.Where(_ => _.Id == id).FirstOrDefault() так это ваще мутотень

Можно писать db.MyObject.FirstOrDefault(_ => _.Id == id)

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

IT>Можно писать db.MyObject.FirstOrDefault(_ => _.Id == id)

так оно, конечно, удобней
кстати, давненько мучает вопрос, да все руки не доходили:

using (var db = new DbManager())
{
    db.MyObject.FirstOrDefault(_ => _.Id == id)
}

не очень удобный финт, с одной стороны, и не ясно как поведет себя код:

IEnumerable<MyObject> SelectByClosure(...)
{
  using (var db = new DbManager())
  {
      return  db.MyObject.Where(...);
  }
}

foreach(var e in SelectByClosure(...))
{
   //...
}

в плане диспоузов и т.п.
где-то тут я видел рассуждения на тему некоего DataContext и умения его открывать\закрывать соединения по мере необходимости

просвяти плз по данному моменту, мож оно как-то лаконичней и удобней можно делать?

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

ili>не очень удобный финт, с одной стороны, и не ясно как поведет себя код:

Упадёт на foreach.

ili>где-то тут я видел рассуждения на тему некоего DataContext и умения его открывать\закрывать соединения по мере необходимости
ili>просвяти плз по данному моменту, мож оно как-то лаконичней и удобней можно делать?

В отличии от DbManager DataContext открывает/закрывает соединение при каждом запросе. Поэтому может использоваться без using. Если у него взвести флаг KeepConnectionAlive, то он будет вести себя в точности как DbManager и будет точно также требовать Dispose.

http://www.bltoolkit.net/Doc.LinqDataContext.ashx

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

D>Мне кажется вы не много не понимаете, большинство пользователей именно этого и хочет. Они хотят что бы объект загрузился при минимальном наборе команд, тонкости реализации им неинтересны.

Такие непритязательные товарищи могут продолжать использовать EF.