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" и иже, хочется сходить в конюшню к конюху и одолжить у него плеть :)

Алексей КЯ считаю такой принцип именования ассоциаций наиболее правильным!
Ты где такую траву берешь? :) Правильнее наименований у вот таких маппингов и быть ничего не может.
Во-вторых, за отсутствие плюрализации - сразу веником из избы!

Алексей КПлюрализация только добавит беспорядка.
Как-раз наоборот, она внесет ясность в именования и сделает модели более понятными.

Алексей КБолее того, я не верю в плюрализацию, которая работает всегда и везьде - это утопия. А раз это так - значит она нах не нужна. В BLToolkit-ном варианте она была (есть), я её убрал.
Ты должен верить в плюрализацию, верь мне. Она работает везде в 99% случаев, а где не работает, используется дефолтное имя. Во-вторых, не плюрализация виновата, а виноват кодирующая db-обезьянка кривожопница, которая нагавняла в именованиях базы.

Алексей КА если между таблицами несколько связей? Вручную будете имена придумывать? Это не наш метод!
Давать пользователю классов самому подправлять, как это сделано в edmx (без потери изменений при ран растоме). В твоем же случае этого нет, разве что выдумывать пользовательские настройки к шаблону, что есть грабли.

Алексей КПо названию видно по каким полям идёт связь. Поначалу тоже было непривычно, потом привык, даже понравилось. :-)
Это утопия. Да ну нах такой гавнокод, друх. Еще раз убедился, что либо человеческий DbFirst с мощным дизайнером и всеми его гибкими настройками, либо человеческий CodeFist для полностью мануального управления классами. Всё остально - какашка без соуса от конструкторов изобретателей, которым заняться нечем :)

Алексей КМСУParent_CatalogId
А вот за такие названия полей в базе вообще нужно <censored/> в сортире. Сделайте нормальные имена полей, и ассоциации будут выглядеть лучше. :-)
А у меня нет таких полей, есть ParentCatalogId. Разницу чуешь? :) Можешь назвать как хочешь, хоть CatalogId.

Алексей Квозможно придётся чуть поправить генератор
Мне не нужно постоянно править генератор, мне нужен полноценный настраиваемый механизм.

Lord BritishА как правильно? ParentCatalogId или CatalogId? А как быть с СУБД в которых это будет выглядеть PARENTCATALOGID и CATALOGID?
Видимо он считает, что Catalogs_Parent_CatalogId_Reference лучше

МСУLord BritishА как правильно? ParentCatalogId или CatalogId? А как быть с СУБД в которых это будет выглядеть PARENTCATALOGID и CATALOGID?
Видимо он считает, что Catalogs_Parent_CatalogId_Reference лучше
Это пестдец, такую шнягу протаскивать в прикладном коде. Ну Лёша порадовал...

Поле MainDataSupplierId развернется в такую траву: SystemSuppliers_MainDataSupplier_MainDataSupplierId_Reference

Расстрелятьвсехнах (c)

Алексей КМежду нами много общего.
Через силу-таки выбросил поделие в облако

P.S. Я негодую ) Для себя еще раз окончательно понял, что либо полноценный ручной кодефирст, либо полноценный автоматический DbFirst с дизайнером.