Привет всем,

Вопрос по ADO.Net Emtity Framework.

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

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

_>Привет всем,

_>Вопрос по ADO.Net Emtity Framework.

_>Если добавить свойство в класс или связь двух классов, то необходимо те же действия повторить на уровне БД или есть какое то действие чтобы изменения отразились в БД?

Можно апдейтить модель по БД, наоборот нельзя. Поэтому сначала надо добавить поле или констрэйнт в БД а потом можно засинхронизировать модель с БД.

А добавлять методы в entity классы и изменять/довлять код в свойства можно?

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

_>А добавлять методы в entity классы и изменять/довлять код в свойства можно?

The generated classes are partial classes, so they can be extended with custom business logic in separate files without interfering with the code generator.
http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx

А про добавление своего кода в свойства пока не нашел...

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

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

_>>А добавлять методы в entity классы и изменять/довлять код в свойства можно?

_>The generated classes are partial classes, so they can be extended with custom business logic in separate files without interfering with the code generator.
_>http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx

_>А про добавление своего кода в свойства пока не нашел...
В свойства EF сущностей код добавляется при помощи механизма partial methods. Вот так выглядит код свойства, сгенерированный дизайнером Entity Framework

public string Region
{
    get
    {
        return this._Region;
    }
    set
    {
        this.OnRegionChanging(value);
        this.ReportPropertyChanging("Region");
        this._Region = global::System.Data.Objects.DataClasses.StructuralObject.SetValidValue(value, true, 50);
        this.ReportPropertyChanged("Region");
        this.OnRegionChanged();
     }
}
private string _Region;
partial void OnRegionChanging(string value);
partial void OnRegionChanged();

Мы можем во-первых реализовать объявленные partial methods OnRegionChanging и OnRegionChanged, во-вторых можно подписаться на события PropertyChanged и propertyChanging

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

S>Можно апдейтить модель по БД, наоборот нельзя. Поэтому сначала надо добавить поле или констрэйнт в БД а потом можно засинхронизировать модель с БД.

Ага! То есть в отличии от ECO сихронизация БД и модели идет с БД. Меняем таблицы и их связи и обновляем после этого классы, а не наоборот.
Спасибо.

stump,
A есть ли возможность разделитьклассы бизнес-сущностей по модулям/пакетам и наследовать класс2 из модели2 от класса1 из модели1?
Я создаю для каждого логического модуля свою диаграмму, но наследоваться от класса, содержащегося в другой диаграммене получается.
Это возможно вообще? Можно ли как то по-другому модульность построить?
...Не представляю себе в настоящий момент как использовать EDF в больших проектах.

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

С>stump,
С>A есть ли возможность разделитьклассы бизнес-сущностей по модулям/пакетам и наследовать класс2 из модели2 от класса1 из модели1?
Конкретно такой вариант реализовать не получится. В модели вся иерархия (базовый класс и наследники) принадлежит одному Entity Set-у. Поэтому в модели 1 будет в принципе доступен класс 2 для которого не определены ни маппинг ни таблцы, и это может привести к нехорошим последствиям.

С>Я создаю для каждого логического модуля свою диаграмму, но наследоваться от класса, содержащегося в другой диаграммене получается.
С>Это возможно вообще? Можно ли как то по-другому модульность построить?
Мне кажется странным разделять модели и иметь для них общие классы. Вы разделяете модели для чего? Вероятно желаете получить какой то уровень изоляции. Зачем же вам тогда общие классы?
В принципе вы можете реализовать свои дата-классы полностью самостоятельно, не наследуясь от EntityObject. Достаточно раелизовать интерфейсы IEntityWithKey, IEntityWithChangeTracker, IEntityWithRelationships или по крайней мере первый из них. Однако при том вы не сможете пользоваться дизайнерами и генерацией кода.
С>...Не представляю себе в настоящий момент как использовать EDF в больших проектах.
Если ваше приложение использует одну БД и оно развертывается на одном хосте, то сколь бы большим оно не было, использование нескольких моделей это не очень хорошее решение для такого случая. Не забывайте что каждая модель это отдельный ObjectContext. Наверняка в БД есть общие данные (типа справочников) и они будут многократно дублироваться во всех контекстах. Работать с этим будет не очень удобно.
Другое дело, когда ваша система использует несколько БД. Либо система имеет несколько хостов (к примеру, ASP.Net web приложение, windows service, пара торйка консольных утилит и т.д.). В этом случае логично создавать отдельные модели для каждой БД и для каждого хоста, включая в них только те сущности, которые нужны.