Дилемма бизнес-объекта C # CSLA: только чтение и чтение / запись

2

Я являюсь частью команды, задачей которой является модернизация нашего старого приложения базы данных VB6 UI/COBOL в наше время. До того, как я был нанят, было принято решение (в основном, по продажам), чтобы повторить пользовательский интерфейс перед базой данных. Итак, теперь мы отлично используем WPF и MVVM, это было потрясающе до сих пор, особенно с использованием CSLA в качестве нашего слоя модели.

Однако, поскольку наша разработка бок о бок со следующей версией старого продукта, мы немного ограничены. Мы не можем вносить изменения (или минимальные изменения) в вызовы, сделанные в базу данных COBOL. До сих пор это было хорошо, хотя и вернулось к дням славы SQL Server, если вы можете поверить в это.

Где я столкнулся с особенно неприятным препятствием, связанным с нашим дизайном BO, речь идет о "легких" бизнес-объектах, возвращаемых в списках и их "полных" коллегах. Позвольте мне попытаться построить пример:

Скажем, у нас есть объект-человек в БД с кучей полей. Когда мы выполняем поиск в этой таблице, мы не возвращаем все поля, поэтому мы заполняем наш объект Lite этими. Эти поля могут быть или не быть подмножеством полного лица. Возможно, мы выполнили соединение или два, чтобы получить другую информацию, относящуюся к поиску. Но если мы хотим отредактировать объект нашего человека, мы должны сделать еще один звонок, чтобы получить полную версию для заполнения пользовательского интерфейса. Это оставляет нас с двумя объектами и пытается манипулировать их состоянием в 1 VM, все время пытаясь сохранить список лиц в синхронизации с любым родительским объектом, который он сидит после удаления, редактирования и добавления. Изначально я делал объект Lite person из ReadOnlyBase < > . Но теперь, когда я имею дело с тем же списком, который у вас был бы со списком полных BOs, за исключением половины полного, наполовину облегченного, я думаю, что я должен был просто сделать как облегченные, так и полные версии из BusinessBase < > и просто сделали частные свойства set lite версии приватными.

Кто-нибудь еще там встретил и нашел решение для этого? После спящего, я придумал это потенциальное решение. Что, если мы завершим полную и облегченную версию нашего BO в другом BO, вот так:

public class PersonFull : BusinessBase<PersonFull>
{
  ...
}
public class PersonLite : BusinessBase<PersonLite>
{
  ...
}

public class Person : BusinessBase<Person>
{
  public PersonFull PersonFull;
  public PersonLite PersonLite;
}
public class PersonList : BusinessListBase<PersonList, Person>
{
}

Очевидно, что все будет зарегистрировано CSLA-свойствами и т.д., но для краткости они являются полями. В этом случае Person и PersonList будут содержать все методы factory. После операции поиска PersonList будет заполнен объектами Person, чьи члены PersonLite были заполнены, а объекты PersonFull были пустыми. Если нам нужно получить полную версию, мы просто скажем объекту Person, чтобы сделать это, и теперь у нас есть наш объект PersonFull, чтобы мы могли заполнить интерфейс редактирования. Если объект Person должен быть удален, мы можем легко сделать это с помощью процедур удаления CSLA на месте, сохраняя при этом целостность наших списков на всех виртуальных машинах, которые его прослушивают.

Итак, я надеюсь, что это имело смысл для всех, и если у кого-то другое решение, которое они успешно использовали или критикуют это, во что бы то ни стало!

Спасибо!

(Отправлено от: http://forums.lhotka.net/forums/thread/35576.aspx)

Теги:
business-objects
read-write
readonly
csla

2 ответа

3 
public class PersonLite : ReadOnlyBase<PersonLite>
{
    public void Update(PersonFull person) { }
}

public class PersonFull : BusinessBase<PersonFull>
{
    // blah blah
}

Я бы обновил объект "lite" с изменениями, внесенными в "полный" объект, и оставьте его как ReadOnlyBase. Важно помнить, что "ReadOnly" в ReadOnlyBase означает объект, который только считывается из базы данных и никогда не сохраняется на нем. Менее элегантное, но более точное имя было бы NotSavableBase, потому что таким объектам не хватает оборудования DataPortal_XYZ для чего угодно, кроме выписок. По очевидным причинам такие объекты обычно имеют непреложные свойства, но им этого не нужно. ReadOnlyBase происходит от Core.BindableBase и реализует INotifyPropertyChanged, поэтому изменение значений его свойств будет очень хорошо работать с привязкой.

Когда вы сохраняете свой "полный" объект, вы передаете вновь сохраненный экземпляр методу Update(PersonFull) экземпляра, который находится в вашем списке, и обновляете свойства объекта "lite" из "полного" объекта.

Я использовал эту технику много раз, и она отлично работает.

Поделиться
-2

Если вы посмотрите на примеры Rocky, которые входят в структуру CSLA, вы заметите, что он всегда отделяет объекты только для чтения от объектов чтения/записи. Я думаю, что это сделано по уважительной причине, потому что поведение будет резко отличаться. Объекты только для чтения будут более ориентированными на производительность, их проверка будет очень различной и, как правило, будет иметь меньше информации. Объекты чтения/записи не будут основаны на характеристиках и в значительной степени зависят от проверки, авторизации и т.д.

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

Что-то вроде этого:

public class PersonLite : BusinessBase<PersonLite>
{
    public PersonLite(PersonFull fullPerson)
    {
        //copy from fullPerson properties or whatever
    }
}

public class PersonFull : BusinessBase<PersonFull>
{
    public PersonFull(PersonLite litePerson)
    {
        //copy from litePerson properties or whatever
    }
}

Вы можете сделать это с помощью шаблона factory, который, как я полагаю, является предпочтением Rocky.

Поделиться
  • 0
    Я не совсем уверен, что вы предлагаете решить. Облегченный BO никогда не заполнит полный BO, так как мы можем просто пойти в БД, чтобы увлажнить полный BO уникальными данными из облегченной версии. Я думаю, я мог видеть полную версию, обновляющую облегченную версию после редактирования, но это не совсем то, что нужно.
  • 0
    Облегченная версия не сможет полностью заполнить полную версию, но этого может быть достаточно, чтобы ее можно было отобразить пользователю, а оставшиеся данные можно было загружать с отложенной загрузкой. Я делал это в прошлом с некоторым успехом. Если вы пытаетесь изменить в памяти объекты, то ваш подход к этому будет совершенно другим.
Показать ещё 3 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню