Мы используем LINQ.
Когда работаеш над dbml файлом в дизайнере автоматом создается DAL-классы.
У нас есть таблица которая имеет несколько ссылок(foreign keys) на таблицу Users.
Как результат автоматом создаются проперти-ассоциации User, User1, User2 ....

Кроме обалденного имени эти проперти еще и меняются местами время от времени при перегенирации.

Как образумить дизйнер? Не хочется удалять этот кусочек ручками каждый раз при перегинерации.


Пример сгенеренного кода

        [Association(Name="User_RunningPrintExtra1", Storage="_User1", ThisKey="CommentUserID", OtherKey="ID", IsForeignKey=true)]
        public User User1
        {
            get
            {
                return this._User1.Entity;
            }
            set
            {
                User previousValue = this._User1.Entity;
                if (((previousValue != value) 
                            || (this._User1.HasLoadedOrAssignedValue == false)))
                {
                    this.SendPropertyChanging();
                    if ((previousValue != null))
                    {
                        this._User1.Entity = null;
                        previousValue.RunningPrintExtras1.Remove(this);
                    }
                    this._User1.Entity = value;
                    if ((value != null))
                    {
                        value.RunningPrintExtras1.Add(this);
                        this._CommentUserID = value.ID;
                    }
                    else
                    {
                        this._CommentUserID = default(Nullable<int>);
                    }
                    this.SendPropertyChanged("User1");
                }
            }
        }
        
        [Association(Name="User_RunningPrintExtra2", Storage="_User2", ThisKey="DistriubutedAsUserID", OtherKey="ID", IsForeignKey=true)]
        public User User2
        {
            get
            {
                return this._User2.Entity;
            }
            set
            {
                User previousValue = this._User2.Entity;
                if (((previousValue != value) 
                            || (this._User2.HasLoadedOrAssignedValue == false)))
                {
                    this.SendPropertyChanging();
                    if ((previousValue != null))
                    {
                        this._User2.Entity = null;
                        previousValue.RunningPrintExtras2.Remove(this);
                    }
                    this._User2.Entity = value;
                    if ((value != null))
                    {
                        value.RunningPrintExtras2.Add(this);
                        this._DistriubutedAsUserID = value.ID;
                    }
                    else
                    {
                        this._DistriubutedAsUserID = default(Nullable<int>);
                    }
                    this.SendPropertyChanged("User2");
                }
            }
        }

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

S>Мы используем LINQ.
S>Когда работаеш над dbml файлом в дизайнере автоматом создается DAL-классы.

Это не DAL, а Entity

S>У нас есть таблица которая имеет несколько ссылок(foreign keys) на таблицу Users.
S>Как результат автоматом создаются проперти-ассоциации User, User1, User2 ....
S>
S>Кроме обалденного имени эти проперти еще и меняются местами время от времени при перегенирации.
S>
S>Как образумить дизйнер? Не хочется удалять этот кусочек ручками каждый раз при перегинерации.
S>

Не пользоваться перегенерацией. Если добавилось поле в существующей таблице — добавить его вручную в дизайнере. Если добавилась одна или несколько таблиц — тогда можно их перетащить из Server Explorer-а.

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

L>Не пользоваться перегенерацией. Если добавилось поле в существующей таблице — добавить его вручную в дизайнере. Если добавилась одна или несколько таблиц — тогда можно их перетащить из Server Explorer-а.

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

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

L>>Не пользоваться перегенерацией. Если добавилось поле в существующей таблице — добавить его вручную в дизайнере. Если добавилась одна или несколько таблиц — тогда можно их перетащить из Server Explorer-а.

S>Мы перегенерируем именно на уровне таблиц.

В дизайнере нет такой возможности — перегенерировать. Ты уверен, что ты именно про Linq to Sql говоришь?

S>А вот реализовывать ручками ссылочные поля — это очень нудно.

Я не предлагаю реализовывать их вручную. Воспользуйся дизайнером.

S>Кроме того это будет дублированием автоматически создаваемых полей

Откуда дублирование?

S>и наверняка повлечет дополнительные траблы.

Не повлечет. Почти год пользуюсь таким подходом. Полет нормальный.

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

S>>Мы перегенерируем именно на уровне таблиц.
L>В дизайнере нет такой возможности — перегенерировать. Ты уверен, что ты именно про Linq to Sql говоришь?
уверен.
1. Даблклик на *.dbml ветке в solution explorer
2. Находим табличкуи удаляем (Del)
3. находем в server explorer нужную табличку и бросаем ее на дизайнер
(та штука, что открылась в п 1)
4. Сохраняем
5. Вуаля



S>>А вот реализовывать ручками ссылочные поля — это очень нудно.
L>Я не предлагаю реализовывать их вручную. Воспользуйся дизайнером.
я объяснил нашу стандартную процедуру.
ваш вариант еще хуже чем комментирование части авто-кода при каждой регенирации.
мне надо каждый раз повторять какую-то серию умных действий в дизайнерею

S>>Кроме того это будет дублированием автоматически создаваемых полей
L>Откуда дублирование?
автоматом создаются пропертя раскрывающие референсы и вы предлагаете реализовывать альтернативные.
хотя возможно вы предлагаете редатировать автоматически созданные, но это не весело
так как это надо будет делать каждый раз.

S>>и наверняка повлечет дополнительные траблы.
L>Не повлечет. Почти год пользуюсь таким подходом. Полет нормальный.
пожалуйста опишите подробнее ваш подход.
Свой я описал в деталях.

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

S>>>Мы перегенерируем именно на уровне таблиц.
L>>В дизайнере нет такой возможности — перегенерировать. Ты уверен, что ты именно про Linq to Sql говоришь?
S> уверен.
S>1. Даблклик на *.dbml ветке в solution explorer
S>2. Находим табличкуи удаляем (Del)
S>3. находем в server explorer нужную табличку и бросаем ее на дизайнер
S> (та штука, что открылась в п 1)
S>4. Сохраняем
S>5. Вуаля

Это не перегенерить, а добавить + удалить. Неудивительно, что дизайнер не сохраняет прежних изменений. Ты же сам ему сказал "удалить"

S>>>А вот реализовывать ручками ссылочные поля — это очень нудно.
L>>Я не предлагаю реализовывать их вручную. Воспользуйся дизайнером.
S>я объяснил нашу стандартную процедуру.
S>ваш вариант еще хуже чем комментирование части авто-кода при каждой регенирации.

Вы правите сгенеренный код?!!

S>мне надо каждый раз повторять какую-то серию умных действий в дизайнерею

Не каждый раз, а только при изменении схемы. И не такие уж умные эти действия.

S>>>Кроме того это будет дублированием автоматически создаваемых полей
L>>Откуда дублирование?
S>автоматом создаются пропертя раскрывающие референсы и вы предлагаете реализовывать альтернативные.
S>хотя возможно вы предлагаете редатировать автоматически созданные, но это не весело

Не надо ничего редактировать. Если у вас есть поле в базе, которое ссылается на какую-то табличку, то дизайнер создаст вам свойство и для поля, и для типизированной ссылки. Если вам не нужно поле, вы можете сделать его private прямо в дизайнере. Если не нужна ссылка, можете указать дизайнеру, что генерить ее не надо.

S>так как это надо будет делать каждый раз.

S>>>и наверняка повлечет дополнительные траблы.
L>>Не повлечет. Почти год пользуюсь таким подходом. Полет нормальный.
S>пожалуйста опишите подробнее ваш подход.
S>Свой я описал в деталях.

Если добавилось поле в существующей таблице — добавить его вручную в дизайнере.
Если добавилась одна или несколько таблиц — тогда можно их перетащить из Server Explorer-а.

Microsoft Visual Studio 2008.
Version 9.0.30729.1 SP

Microsoft .Net Framework
Version 3.5 SP1

Если это имеет значение.

Извините за грамматические ошибки:
пишу быстро, но не всегда правильно.

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

L>Если добавилось поле в существующей таблице — добавить его вручную в дизайнере.
L>Если добавилась одна или несколько таблиц — тогда можно их перетащить из Server Explorer-а.

В том-то и дело.
Никто ручками прописывать новые поля в дизайнере не хочет.
Мы стараемся избежать интелектуальных действий в этом вопросе.

Мы перегенерируем (если вам угодно "добавляем\удаляем") Entity
для таблицы каждый раз когда меняется ее структура.
Весь Custom код в partial class-ах.
Но иногда нельзя/трудно бороться с автоматическим генерируемым кодом.
Как в этом случае.
Неужели трудно понять подход и проблему?

Здравствуйте, Lloyd, Вы писали:
L>Вы правите сгенеренный код?!!

Очень редко, но таки комментируем.

Хотя бы это:
Как перекрыть дефаултовый конструктор из контекста,
который упорно использует локальный для DLL конфиг
(а не веб конфиг) для получения connection string.

Хотя это и не тема данного топика.

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

L>>Если добавилось поле в существующей таблице — добавить его вручную в дизайнере.
L>>Если добавилась одна или несколько таблиц — тогда можно их перетащить из Server Explorer-а.

S>В том-то и дело.
S>Никто ручками прописывать новые поля в дизайнере не хочет.
S>Мы стараемся избежать интелектуальных действий в этом вопросе.

S>Мы перегенерируем (если вам угодно "добавляем\удаляем") Entity
S>для таблицы каждый раз когда меняется ее структура.
S>Весь Custom код в partial class-ах.
S>Но иногда нельзя/трудно бороться с автоматическим генерируемым кодом.
S>Как в этом случае.
S>Неужели трудно понять подход и проблему?

Ваша проблема порождена вашим подходом. Смените подход и проблема исчезнет.
Ничего интеллектуального в добавлении новоро поля нет.

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

L>Ваша проблема порождена вашим подходом. Смените подход и проблема исчезнет.
L>Ничего интеллектуального в добавлении новоро поля нет.

Регинерация -это удобно ( time =5 min)
Правка в базе и синхронная правка на диаграмме -это удобно
( time = 15 min+ошибки+ необх. помнить что у нас есть одна такая *тая таблица)

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

L>>Вы правите сгенеренный код?!!

S>Очень редко, но таки комментируем.

//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:2.0.50727.3053
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

Для кого писали?

S>Хотя бы это:
S>Как перекрыть дефаултовый конструктор из контекста,
S>который упорно использует локальный для DLL конфиг
S>(а не веб конфиг) для получения connection string.

Опять мимо. ConnectionString берется из ConnectionString-ов конфига приложения.

S>Хотя это и не тема данного топика.

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

L>>Ваша проблема порождена вашим подходом. Смените подход и проблема исчезнет.
L>>Ничего интеллектуального в добавлении новоро поля нет.

S>Регинерация -это удобно ( time =5 min)

Судя по тому, к каким проблемам это приводит — это все-таки не очень удобно.

S>Правка в базе и синхронная правка на диаграмме -это удобно
S>( time = 15 min+ошибки+ необх. помнить что у нас есть одна такая *тая таблица)

Какие 15 минут? Пару суток как минимум нужно, чтобы скопипастить нужную строчку в dbml-е.

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

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

L>>>Вы правите сгенеренный код?!!

S>>Очень редко, но таки комментируем.

L>

L>//------------------------------------------------------------------------------
L>// <auto-generated>
L>// Changes to this file may cause incorrect behavior and will be lost if
L>// </auto-generated>
L>//------------------------------------------------------------------------------

L>Для кого писали?
к чему это? тест на знание английского?

S>>Хотя бы это:
S>>Как перекрыть дефаултовый конструктор из контекста,
S>>который упорно использует локальный для DLL конфиг
S>>(а не веб конфиг) для получения connection string.

L>Опять мимо. ConnectionString берется из ConnectionString-ов конфига приложения.
правильно. DBML файл в DLL для разделения логики.
По умолчанию Настройки берутся из конфига DLL.
Но DLL используется на веб сайте.
Либо вы действительно не понимаете либо "дурачка включили"

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

L>Судя по тому, к каким проблемам это приводит — это все-таки не очень удобно.
Судя по тому как вы помогаете и сколько времени на вас ушло, то лучше бы вы молчали.
Толку от Ваших ответов ноль. У меня нет ни времени ни желания объяснять Вам подробно
чем ваш вариант хуже устоявшегося у нас.
Тем более что я это уже раз сделал.

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

L>>Судя по тому, к каким проблемам это приводит — это все-таки не очень удобно.
S>Судя по тому как вы помогаете и сколько времени на вас ушло, то лучше бы вы молчали.
S>Толку от Ваших ответов ноль. У меня нет ни времени ни желания объяснять Вам подробно
S>чем ваш вариант хуже устоявшегося у нас.
S>Тем более что я это уже раз сделал.

Только хамить не надо.
С вашими проблемами на проекте мы уже сталкивались и я описал тот вариат, к которому в итоге пришли. Использовать его или нет — дело ваше.

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

S>>>Хотя бы это:
S>>>Как перекрыть дефаултовый конструктор из контекста,
S>>>который упорно использует локальный для DLL конфиг
S>>>(а не веб конфиг) для получения connection string.

L>>Опять мимо. ConnectionString берется из ConnectionString-ов конфига приложения.
S>правильно. DBML файл в DLL для разделения логики.
S>По умолчанию Настройки берутся из конфига DLL.

Ключевое слово — по умолчанию. Никто не мешает в web.config-е строку соединения перекрыть. А раз так, то зачем тогда переписывать кончтруктор дата-контекста — не понятно.

S>Но DLL используется на веб сайте.
S>Либо вы действительно не понимаете либо "дурачка включили"

Я не включал дурочка. Перед тем как отвечать, я перепроверил, действительно ли можно подменить строку соединиения в конфиге приложения и убедился, что все-таки можно это сделать.

С Вами разговаривать безрезультатно.
Спасибо за желание помочь.


Кто-нибудь знает как разрешить чисто техническую проблему?

В принципе будет достаточно ПРОГРАМНОЙ
(в custom части partial класса Enity)
readonly property со СТАТИЧЕСКИМ именем.
Программа максимум — чтобы она была writable.

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

S>У нас есть таблица которая имеет несколько ссылок(foreign keys) на таблицу Users.
S>Как результат автоматом создаются проперти-ассоциации User, User1, User2 ....
S>Кроме обалденного имени эти проперти еще и меняются местами время от времени при перегенирации.
S>Как образумить дизйнер? Не хочется удалять этот кусочек ручками каждый раз при перегинерации.

Если я правильно понимаю проблему, то желаемое имя проперти-ассоциации можно задать в свойствах самой ассоциации (в дизайнере — правый клик на ассоциации + Properties -> ChildProperty.Name || ParentProperty.Name; в .dbml файле — аттрибут Member тега Association)
Если ассоциация/поля просто не нужны — можно их удалить из дизайнера/dbml
Править сгенеренный файл — не очень хорошая идея — хотя что-то можно там "подправить" имплементаций partial класса (сгенеренный файл же там partial) — полей например добавив, логики...
К ложалению синхронизации dbml с БД схемой в Linq2Sql нет (или я не нашел?) так что при изменениях приходится либо удалять + заново таскать измененные таблици либо руками менять dbml (что не очень сложно, в общем-то). В условиях если много "руками измененных" ассоциаций — проще конечно же вносить изменения тоже руками. Особых проблем с этим у нас на проекте замечено не было, впрочем..

хочеш сделать что-то хорошо — сделай сам!

        private EntityRef<User> _CirculationUser;
        [Association(Name = "RunningPrintExtra_CirculationUser", Storage = "_CirculationUser", ThisKey = "CirculationUserID", OtherKey = "ID", IsForeignKey = true)]
        public User CirculationUser
        {
            get
            {
                return this._CirculationUser.Entity;
            }
        }


        private EntityRef<User> _ProductionDateUser;
        [Association(Name = "RunningPrintExtra_ProductionDateUser", Storage = "_ProductionDateUser", ThisKey = "ProductionDateUserID", OtherKey = "ID", IsForeignKey = true)]
        public User ProductionDateUser
        {
            get
            {
                return this._ProductionDateUser.Entity;
            }
        }

в принцитпе возможен и сеттер, ноего не тестировал.