Обеспечить целостность данных между различными объектами

Question

Я изучаю ООП, разрабатывая программное обеспечение для управления музыкой на C #.До сих пор я изложил взаимодействие различных классов и объектов, как показано на этой диаграмме классов http://img811.imageshack.us/img811/7624/classdiagramh.png

Я, однако, очень растерян, пытаясь сделать свой дизайн более четким, поскольку нахожу несметное количество возможностей того, каквсе можно сделать, но я не хочу в конечном итоге с плохим дизайном.Основная проблема, с которой я сталкиваюсь, - обеспечить целостность данных между различными объектами. (Насколько я понимаю, я предполагаю, что в ООП, как и при проектировании баз данных, есть способ обеспечить точность, согласованность и надежность.хранения данных в другом объекте, как это делается при проектировании базы данных (например, использование ограничения внешнего ключа). Например, в моем приложении у меня есть объекты Artist, Song и Album, которые должны взаимодействовать вместе. Я не хочу, чтобыНапример, песня связана с неправильным альбомом по ошибке. Мне сказали, что я должен сделать что-то вроде:

class Album
{
  public String Name{ get; set;}

  List<Track> tracks;

  public void AddTrack(Track t)
  {
    tracks.Add(t);
    t.Album = this;
  }
} 
class Track
{
  public Album Album{ get; set;}
  public String AlbumName
  { 
    get{ return this.Album.Name}
  }

  public String ArtistName{ get; set}
}

Однако это не работает для меня. Может кто-нибудь подсказать, как я могу это сделать?В частности, как я могу добавить новую песню с названием, альбомом и исполнителем и убедиться, что если по какой-то странной причине название альбома будет изменено, все треки все равно будут возвращать правильное название альбома, так как онивы получаете данные из самого альбома?

Также можноomeone предлагает лучший дизайн.Должен ли я использовать наследование или какой-либо полиморфизм, чтобы сделать мой дизайн надежным?

Answer 1

На самом деле вы не делаете ассоциации.

В объектно-ориентированном программировании вы ассоциируете объекты вместо "ключей".Понятия «внешний ключ» не существует.

Если у объекта B есть родительский объект A, а у A есть уникальный идентификатор , вы не будете связывать родительский объект B, установив этот параметр уникальный идентификатор , но сам объект:

B имеет родителя A :

public class A { public Guid ID { get; set; } }
public class B { public A Parent { get; set; } }

A someA = new A();
B someB = new B();
someB.Parent = someA;

Работая таким образом, можно связать «экземпляр A»со многими другими объектами, заменяя тот же объект из любой ссылки, приведет к изменению этого объекта .

Как достичь ограничений целостности?Существуют некоторые шаблоны проектирования, но один из наиболее распространенных - это Спецификация .

Это создает общий интерфейс "ISpecification", который имеет метод, который можно назвать "Проверка", который принимаетаргумент - объект для проверки на спецификацию -.В реализациях этот метод будет проверять, что некоторый объект соответствует некоторой спецификации.

public interface ISpecification { bool Check(object some); }

public class Person { public string Name { get; set; } }

public class PersonSpecification : ISpecification
{
     public bool Check(object some) 
     {
          // Checks that some person won't be null and his/her name isn't null or empty
          return some != null && !string.IsNullOrEmpty(((Person)some).Name);
     }
} 

Это очень простой и общий пример того, как реализовать бизнес-правила и / или ограничения.

There 'Есть много фреймворков, которые могут помочь вам в этой области:

• Блок проверки шаблонов и практик Microsoft: http://msdn.microsoft.com/en-us/library/ff648831.aspx

• Валидатор NHibernate: http://nhforge.org/wikis/validator/nhibernate-validator-1-0-0-documentation.aspx (это часть проекта NHibernate, но его можно использовать автономно без NHibernate).

В некоторых проектах я включил NHibernate Validator, а в других - настраиваемое решение на основе Спецификация шаблон, но более сложный и гибкий способ, чем образец.

О спецификации шаблон:

• http://en.wikipedia.org/wiki/Specification_pattern

Answer 2

Как и в дизайне БД, вы должны сделать свой выбор в соответствии с требованиями вашего бизнеса.Значит: Вы должны задать себе вопросы о возможных созвездиях - все ли песни на компакт-диске одного и того же исполнителя?Нет -> поле исполнителя на дорожке, да -> поле исполнителя на альбоме - нужно ли вам получать альбом, когда вы знаете дорожку, или только все дорожки из определенного альбома - ...

То, что вы делаете, правильно в том смысле, что вы ссылаетесь из объекта Track на название упоминаемого альбома.Что следует упомянуть: они возвращают название альбома, но только имя, которое альбом имеет в момент GET.Так что, если вы присвоили свойству AlbumName визуальный элемент управления или что-то еще, оно не будет обновляться автоматически при изменении имени Альбомов.

, если это не то, что вы хотите услышать, спросите более конкретно.