МСУАлексей КДизайнер и 100+ таблиц == жесть.
Никакая не жесть, уже обсуждали. В EF6 оптимизировали его, я загружал больше > 1K таблиц, вообще летает. И даже с 10K таблицами можно работать.Да дело не в скорости, пусть оптимизировали, верю. Мне просто страшно представить диаграмму из 10K квадратиков. Что с ними делать-то?

МСУАлексей КИгры разума с плюрализаторами мне ни к чему. Чем проще - тем лучше!
Никаких игр, мы просто называем вещи своими именами, код становится на порядки читабельнее. Просто один раз назови по-человечески и оно поплывет. Вот представь, если бы тебя родители назвали не Алексей, а SenderPersID_Reference? Ну вот им было бы так проще, к примеру. Как жить с таким именем? SenderPersID_Reference - очень удобно, рекомендую!

МСУСабж:

NechtoЗдравствуйте.

Предложите пожалуйста пути решения вопроса.

Имеется приложение, в котором реализован частично mapping порядка 40 таблиц базы данных MSSQL. Всего в этой базе данных порядка 300 таблиц.
Теперь появилась необходимость в приложении реализовать возможность получения данных из этих таблиц. Соответственно в идеале нужно делать mapping всех остальных таблиц, но для этого нужно переехать жить на работу. Так как в этих таблицах хренова куча полей.

Мои решения:
- Реализовать средствами EF Data Model базы данных, то есть слепок. Такой вариант не очень нравится поскольку делает винегрет из приложения.

- Сформировать список из названий таблиц и путем SQL поднимать данные из БД.
Только не пойму как это можно реализовать через EF?

Забудь, ТС куда-то пропал...

МСУВот представь, если бы тебя родители назвали не Алексей, а SenderPersID_Reference? Ну вот им было бы так проще, к примеру. Как жить с таким именем? Мда... задумался... пойду покурю...

МСУАлексей КДа дело не в скорости, пусть оптимизировали, верю. Мне просто страшно представить диаграмму из 10K квадратиков. Что с ними делать-то?
Ну это из области фантастики. Таблицы сгенерил SQL курсором, потом вкорячил их в модель. В идеале даже 100 классов многовато для одной модели... Разноси EF модель на EF диаграммы. Каждая диаграмма отображается в виде отдельного окна в дизайнере. Я не понимаю, зачем тебе сразу видеть все 100 классов? Учись работать с EF, милок. Хватит ныть! :)Модель разделили на несколько диаграмм сравнительно недавно. Я не мог ждать, пока они это родят. А теперь уже поздно, у меня есть самописные инструменты, которые меня устраивают.

МСУАлексей КМодель разделили на несколько диаграмм сравнительно недавно. Я не мог ждать, пока они это родят.
Ты издеваешься? :) Да им уже сто лет! http://msdn.microsoft.com/en-us/data/entity-framework-multiple-diagrams-per-model.aspx Я начал использовать EF раньше.

МСУАлексей КА теперь уже поздно, у меня есть самописные инструменты, которые меня устраивают.
Не гунди. Нужно идти вперед, немного выпиливая бревна из ресниц. Иначе потонешь в болоте. В любом случае, инспекция кода тебе не помешает. Проведи глобальный рефакторинг, оцени, подумай, взвесь. Проще всего от всего отмахиваться и плеваться. Меняй позицию, двигайся вперед, а не назад. На полном серьезе. Всегда есть возможность найти компромисс, так найди его!Зачем, если проекты работают, экономический эффект положительный, все довольны.

МСУАлексей К, аргумент "всё и так уже работает" - уныл как класс. То, что уже 100 лет работает без прикасания к коду - пусть работает. Но то, с чем ты работаешь постоянно, нужно 100% модифицировать под новые рельсы. Не в тупую, конечно, но двигаться в этом направлении. Иначе какой же ты джедай? Зачем менять то, что мне нравится? Я люблю, когда ничего лишнего.

МСУАлексей КЯ начал использовать EF раньше.
Верю. Но как только появились 2 года назад в EF5 (VS12) диаграммы, что мешало раскидать модель по ним?Я никогда не пользовался EF дизайнером, у меня всегда был свой кодогенератор. Сначала на базе BLToolkit, потом не поленился, написал свой.

МСУАлексей КЗачем, если проекты работают, экономический эффект положительный, все довольны.
Всё само никогда не работает, это фантастика. Постоянно бизнес хочет чего-то нового, доработок, новых веток решения, плюшек и пирожков. Ну ты мне не рассказывай сказки. У программиста всегда будет работа. Сидеть над тухляком, который "работает", может только админ. Ты давай не включай заднюю. :)Бизнесу пофиг, как я работаю с EF, это его не касается. Я же не спрашиваю, как они обеспечивают бюджет проекта.

МСУАлексей КЗачем менять то, что мне нравится? Я люблю, когда ничего лишнего.
Нравятся костыли, подпорки и метание гавна по стенам туалета? Ну люби, мне-то чего. Даю добро :)Я знал, что ты не против.

hVosttАлексей КНа уровне БД валидация тоже не нужна? Ну давай делать все поля необязательными.

Проверять надо, но ты там стряпаешь сообщения для пользователя, значит контекст у тебя занимается валидацией пользовательского ввода. Гавнецом попахивает Думаешь, что нет валидации в других слоях, в том числе на клиенте ? Откуда такая уверенность?

hVosttМСУВ MVVM никакие DTO не нужны, всё можно сделать на чистых entities.

Просто аншлаг. Уносите этого пациента, он неизлечимо болен.

Серьёзно, больше не пиши такой чуши. Написанное уместно только программульки масштаба лабораторной работы пединститута. Не тупи короче. В энтерпрайзе этот поросячий гон не прокатит. Не позорься.Специальные DTO нужны там, где они действительно нужны. Они нужны только в случае, когда контракт веб-сервиса не должен зависеть от других частей информационной системы. В остальных случаях от DTO больше вреда чем пользы.

hVosttАлексей КДумаешь, что нет валидации в других слоях, в том числе на клиенте ? Откуда такая уверенность?

блин, ты прописываешь пользовательские сообщения для атрибутов Required и MaxLength, значит собираешься их показывать, разве нет? всё что не залезло в конекст, это однозначно внутренняя ошибка, и пользователь не должен знать их причин, это недоработка клиентской валидации, и выполнять чужую работу датаконтекст не должен.Не сделаны "user readable" сообщения на всякий случай , что теперь?

hVosttвот и я ничего не понялЕсли ничего не понял, зачем критикуешь?