Комментарии 15
Спасибо за хороший материал.
Очень познавательно, спасибо
В свое время изрядно по гемороился с с этими дизайнерами в вижуал студии. Считаю, что лучший и наиболее прозрачный способ описания маппингов — руками в хмл.
Спасибо.
А не в курсе, что из этого можно провернуть в Linq to SQL? Т.е. можно ли так же пронаследовать два класса из разных таблиц, из одной.
А не в курсе, что из этого можно провернуть в Linq to SQL? Т.е. можно ли так же пронаследовать два класса из разных таблиц, из одной.
«Заходим в студию, в наш проект базы данных и обновляем нашу схему из БД. При этом должна появиться новая Entity BlogPost. Всё отлично, появилась. Даже со связью. Удаляйте эту связь первым делом. В наследованных Entity она нам не нужна.»
Удалять эту связь мне придется каждый раз при обновлении схемы из БД?
Удалять эту связь мне придется каждый раз при обновлении схемы из БД?
Хороший вопрос. Только что проверил, второй раз связь не вылезала, и повторно удалять ничего не придётся.
Спасибо.
Это хорошо, наверное.
Но в этом случае нужно обязательно уметь понимать, проапдейчена уже схема или нет. Естественно не анализируя саму схему.
Иначе получается жутко непрозрачная штука, с которой страшно работать :)
Это хорошо, наверное.
Но в этом случае нужно обязательно уметь понимать, проапдейчена уже схема или нет. Естественно не анализируя саму схему.
Иначе получается жутко непрозрачная штука, с которой страшно работать :)
Там просто можно выбирать те таблицы, которые надо апдейтить. Сейчас я проапдейтил BlogPost но связь не вылезла.
Это не решение.
Представьте себе проект с кол-вом таблиц > 100, со сложными связями между ними. В какой-то момент вы захотите изменить метаданные одной из существующих таблиц, и соответствующим образом обновить схему (которая заметьте, уже до этого была не native, уже была хакнута). Несколько увлекательнейших часов поиска различий между схемами вам обеспечены.
Возможно структура метаданных схемы хоть как-то читабельна и её можно править ручками… Во всяком случае это было бы хорошо. Получился бы эдакий Microsoft NHibernate. :)
Представьте себе проект с кол-вом таблиц > 100, со сложными связями между ними. В какой-то момент вы захотите изменить метаданные одной из существующих таблиц, и соответствующим образом обновить схему (которая заметьте, уже до этого была не native, уже была хакнута). Несколько увлекательнейших часов поиска различий между схемами вам обеспечены.
Возможно структура метаданных схемы хоть как-то читабельна и её можно править ручками… Во всяком случае это было бы хорошо. Получился бы эдакий Microsoft NHibernate. :)
Ну, скажем так, в таком проекте я работал с Team Foundation Suite. В нём есть отличный комперер данных и система отката 8-) Так что всё становится проще, когда инструменты работают лучше. Думаю, МСовский редактор не единственный, да и как показала моя практика — 50% забугорных программеров вообще работают со схемой ХМЛ.
Ну, а в общем — я соглашусь, идеальных инструментов не бывает 8-)
Ну, а в общем — я соглашусь, идеальных инструментов не бывает 8-)
Очень здорово:) Однако, не совсем понятно, какая именно система делается и что она будет делать:)
Эм, скажем так, я ещё не решился. То ли это будет спец система блогопостинга, то ли просто система для мучения и обучения 8-)
Есть возможность реализовать систему учета расхода собственных средств и планирования расходов на какой-то период:) Это моя система мучения, но, имхо, в отличие от вашей, у меня есть один клент — моя знакомая и я сам:)
Интерфейсы для сервисов данных я уже прописал. Если в кратце, то мы можем скооперироваться — я останусь со своим клиентом, а вы можете плескаться в данных как вам угодно. Первоначальная схема данных очень простая. Но ее потом можно усложнить.
Можно почитать тут:
acerv.livejournal.com/278203.html
Там по ссылкам «тут» можно провалится в самое начало.
Интерфейсы для сервисов данных я уже прописал. Если в кратце, то мы можем скооперироваться — я останусь со своим клиентом, а вы можете плескаться в данных как вам угодно. Первоначальная схема данных очень простая. Но ее потом можно усложнить.
Можно почитать тут:
acerv.livejournal.com/278203.html
Там по ссылкам «тут» можно провалится в самое начало.
Приведите, пожалуйста, запросы к унаследованным entity
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наследование в ADO.NET Entity Framework