Алексей КLord BritishКто-нибудь вообще коде фирстом пользуеццо?Причём весьма успешно.
+1, CodeFirst - рулит, DbFirst - гумно )

P.S. Кодартиклс на фирсте состряпан )

Алексей КМСУP.S. Кодартиклс на фирсте состряпан )Неожиданно...
Нужно быть в тренде :)

Кстати, Лёня, ну-ка предъявите свой шаблончик для фирста, если он будет приятен, закину его в базейку знаний :)

P.S. Принципиальное требование , чтобы гавношаблон генерил вот такую плюшку: http://codearticles.ru/Home/ArticleView/2144

netivanМСУ, а че не http://visualstudiogallery.msdn.microsoft.com/5d663b99-ed3b-481d-b7bc-b947d2457e3c ?
Там чё, нужно сначала генерить свою edmx по $edmxInputFile$, а потом перегенерять контекст на новые рельсы? Разработчик этого поделия что, травы укурился? :)

Алексей КМСУКстати, Лёня, ну-ка предъявите свой шаблончик для фирста, если он будет приятен, закину его в базейку знаний :)

P.S. Принципиальное требование , чтобы гавношаблон генерил вот такую плюшку: http://codearticles.ru/Home/ArticleView/2144 Берём тэтэшник из BLToolkit, переделываем под себя. Времени требуется часа два, не меньше. :-)
Я не спрашивал что-откуда нужно взять и что-куда нужно положить, а тем более сколько времени на это нужно... :)

netivanМСУ, очень удобно - за тебя все генерится. по своему усмотрению можешь менять выходной код, логику генерации. Лично мне подход крайне удобен.
Смысл кодефирста в полностью оторванных от БД классах - чистые непорченные сущности (можешь маппинги атрибутами натягивать или через флюент, как в хибе). Если же использовать твой способ (и Лёнин тоже, пока он не показал мне t4), то не вижу особой разницы между классическим DbFirst, в котором, кстати, есть полноценный гламурный дизайнер.

netivanЛично мне подход крайне удобен.
Ты вдумайся в саму паранормальность идеи - сгенерить edmx в дизайнере с автогенеренной моделью, подключиться к нему из гавношаблона и еще разок нагенерить чистых проксей. Только идиоту придет в голову такая идея.
Хотя бы такой подход - http://codearticles.ru/Home/ArticleView/1168 (сам писал, но там еще допиливать под хранимки нужно). Но не то, что ты предлагаешь.

Алексей КПросто это не чисто моё решение, поэтому публиковать его я немного стесняюсь. Вдруг кто обидится, на и некрасиво как-то... :-)
не подумумай, что я клещ какой-то, но... :)Жарю ультрамальвин
И танцую один
Остальные стесняются
Не надо стесняться

Алексей КnetivanНе совсем. Это лишний слой, который требуется синхронизировать с БД . Зачем ещё какие-то метаданные, если их и без того в БД хватает.
+1, в двух местах нужно обновлять контексты - это идиотизм.

ViPRosговно все это
Датасеты наше всё, начальник?

ViPRos, ну так а в чем непрозрачность кодефирста? Только честно, вообще работал с энтити? :)

По-хорошему в фирсте кодогенерация по шаблону нафиг не нужна. По сути прибиваемся снова гвоздями к базе данных.

Алексей КnetivanДля меня основной плюс DbContext это производительность в новых версиях EF.DbContext по своей природе не может работать быстрее ObjectContext. :-)
http://codearticles.ru/Home/ArticleView/2148

Алексей КМСУПо сути прибиваемся снова гвоздями к базе данных.И это хорошо.
Да, но для CodeFirst подхода :) А то используем фирст, а без базы жить не можем.

Алексей КМСУпропущено...
Да, но для CodeFirst подхода :) А то используем фирст, а без базы жить не можем.Я использую не code-first, а DbContext API. :-)
Выкрутился :)

Алексей К в EF присутствует некоторый бардак с названиями.
Ну почему же :)

http://msdn.microsoft.com/en-us/data/gg192989.aspx Version 4.1 of the Entity Framework contains both the Code First approach and the new DbContext API. This API provides a more productive surface for working with the Entity Framework and can be used with the Code First, Database First , and Model First approaches.

netivanДа, кодогенерацию из edmx попробуйте, вы же любите эксперименты :)
Ну он сказал уже, что в топку. Ибо там начинаются тормоза при большом количестве сущностей. Это основная причина того, что edmx отправляется на помойку.

netivanАлексей К, вы кстати свой шаблон так и не показали. Секрет фирмы ?
+1

Да, да, Лёня, колись давай. А я тебе за это расскажу, как такой мощнейший полнотекстовый поиск сделал http://codearticles.ru/Home/Search

netivanАлексей К,

погодите, может быть я не понимаю. Каким образом edmx будет тормозить?

http://stackoverflow.com/questions/6185918/entity-framework-4-1-for-large-number-of-tables-715

Конкретный ответLarge database is always something special. Any technology has some pros and cons when working with a large database.

The problem you have encountered is the most probably related to building the model. When you start the application and use EF related stuff for the first time EF must build the model description and compile it - this is the most time consuming operation you can find in EF. Complexity of this operation grows with number of entities in the model. Once the model is compiled it is reused for the whole lifetime of the application (if you restart the application or unload application domain the model must be compiled again). You can avoid this by precompiling the model. It is done at design time where you use some tool to generate code from the model and you include that code into your project (it must be done again after each change in the model). For EDMX based models you can use EdmGen.exe to generate views and for code first based models you can use EF Power Tools CTP1.

EDMX (the designer) was improved in VS 2010 SP1 to be able to work with large models but I still think the large in this case is around 100 entities / tables. In the same time you rarely need 715 tables in the same model. I believe that these 715 tables indeed model several domains so you can divide them into multiple models.

The same is true when you are using DbContext and code first. If you model a class do you think that it is correct design when the class exposes 715 properties? I don't think so but that is exactly what your derived DbContext looks like - it has a public property for each exposed entity set (in the simplest mapping it means one property per table).

Same entity can be used in multiple models but you should try to avoid it as much as possible because it can introduce some complexities when loading entity in one context type and using it in other context type.

Code only = code first = Entity framework when you define mapping in the code without using EDMX.

Алексей КА пожалуйста. :-)



За такие классы в прикладном коде, Лёша, с именованиями типа "Articles_Catalog_CatalogId_Reference", "Catalogs_Parent_CatalogId_Reference" и иже, хочется сходить в конюшню к конюху и одолжить у него плеть :)