(no subject)

[pechkin]

Интересуюсь идеями на тему толкового разделения data context и entity в LINQ to SQL. То есть, как бы так взаимно расположить entities, класс DataAccess, который будет ходить в dbml, и сам dbml, чтобы сторонний проект мог референсить ентити и дата-аксесс, ничего не зная про дбмл, но получать от дата-аксесса ентитиз, которые надстроены над объектами дбмля. Пока что я придумал два способа, но оба мне не нравятся по разным причинам.

Кто как делает?

Comments

[natsla.livejournal.com]

гештальт, спасибо.

[matveich.livejournal.com]

А какой смысл скрывать DBML? Типа хочешь скрыть настоящие связи между таблицами? Так нет смысла, у тебя и так у всех объетов все properties будут видны, по ним DBML можно воссоздать без проблем.

Короч, тебе зачем??

[pechkin.livejournal.com]

Я бы пользовался вообще табличными ентитями, но они как-то недостаточно: скажем, первый же енумерэйшън в них и конвертация его в какой-нибудь базовый интеджер (ну, на самом деле байт, я же скупердяй известный) уже требует какой-то надстройки над табличной ентитью. И к тому же, там названия полей придуманы предыдущими программерами, и они мне не нравятся, я не хочу ими пользоваться. Мне, может быть, для рефлекшъна даже понадобятся более нормальные названия полей - скажем, чтобы у всех ентитей ID назывался идом, а не [A-Z]+_ID.

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

То, что я сделал пока что - это опубликовал только ентити, а методы, лазящие в базу, сделал статическими методами ентитей (ну, и не-статическими тоже иногда). И описал в отдельном файле в парциальных классах. Но мне этот подход не нравится - точнее, он мне кажется каким-то очень кустарным и самодельным. Поискал best practices - не нашел пока.

[matveich.livejournal.com]

Все правильно. Либо юзаешь partial classes, либо пишешь свои классы, и в довесок пишешь пачку type converters.

Есть еще один способ, можно овверайднуть тайпы генератор который генерит классы из dbml, короч написать свой генератор и настроить vs его юзать. Это сложно, но выполнимо. У этого метода есть один существенный недочет. Этот генератор придеться ставить на все тачки девелоперов, которые изменяют этот самый dbml. К тому же не исключено что он вообще будет нужен в последствии и во время любой компиляции.

[pechkin.livejournal.com]

Ой-ой-ой, как сложно и грозно. Я лучше тишком, по-пластунски, парциальными классами. Причем в один файл сложил все, что касается насадок над полями объектов, а в другой вынес все методы их добывания, сделав их статическими. Типа

в dbml.designers.cs:

  [Table(Name="dbo.AdSources")]

  public partial class AdSource : INotifyPropertyChanging, INotifyPropertyChanged

  {

    private static PropertyChangingEventArgs emptyChangingEventArgs = new PropertyChangingEventArgs(String.Empty);

    private int _AS_ID;

    private string _AS_NAME;

...

}

в Entities.cs:

  public partial class AdSource 

  {

    public string Name { get { return AS_NAME; } set { AS_NAME = value; } }

  }

и в DataAccess.cs:

  public partial class AdSource

  {

    public static AdSource DBGet(string adSourceName)

    {

      using (IgnitAdDataContext db = new IgnitAdDataContext())

      {

        return db.AdSources.SingleOrDefault(s => s.AS_NAME.Equals(adSourceName));

      }

    }

  }