Я являюсь частью команды, которой поручено обновить наше старое приложение базы данных VB6 UI / COBOL до современных времен. Перед тем, как меня наняли, было принято решение (я уверен, в основном, из-за продаж) переделать пользовательский интерфейс перед базой данных. Итак, теперь мы используем WPF и MVVM с большим эффектом, до сих пор это было потрясающе, особенно использование CSLA в качестве нашего уровня модели.
Однако, поскольку наша разработка ведется параллельно со следующей версией старого продукта, мы немного ограничены. Мы не можем вносить какие-либо изменения (или минимальные изменения) в вызовы, сделанные в базе данных COBOL. До сих пор это было хорошо, хотя, если вы можете в это поверить, возвращаетесь к временам славы SQL Server.
Там, где я столкнулся с особенно неприятным препятствием в отношении нашего дизайна BO, является работа с «легкими» бизнес-объектами, возвращаемыми в списках, и их «полными» аналогами. Позвольте мне попытаться построить пример:
Допустим, у нас есть объект person в БД с кучей полей. Когда мы выполняем поиск в этой таблице, мы не возвращаем все поля, поэтому мы заполняем ими наш облегченный объект. Эти поля могут быть или не быть подмножеством полного человека. Возможно, мы сделали соединение или два, чтобы получить некоторую другую информацию, специфичную для поиска. Но если мы хотим отредактировать наш объект person, мы должны сделать еще один вызов, чтобы получить полную версию для заполнения пользовательского интерфейса. В результате у нас остается два объекта и мы пытаемся манипулировать их состоянием в одной виртуальной машине, все время пытаясь сохранить синхронизацию списка людей на любом родительском объекте, который он находится после удаления, редактирования и добавления. Изначально я сделал наш объект lite person производным от ReadOnlyBase ‹>. Но теперь, когда я имею дело с тем же поведением списка, что и со списком полных BO, за исключением наполовину заполненных, наполовину облегченных, я думаю, мне следовало просто сделать как облегченную, так и полную версии производными от BusinessBase ‹ > и просто сделал свойства установщика облегченной версии закрытыми.
Кто-нибудь еще сталкивался и нашел решение для этого? Выспавшись на нем, я придумал это потенциальное решение. Что, если мы заключим полную и облегченную версию нашего 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 будут содержать все фабричные методы. После операции поиска PersonList будет заполнен объектами Person, все члены PersonLite которых были заполнены, а объекты PersonFull были пустыми. Если нам нужно получить полную версию, мы просто говорим об этом объекту Person, и теперь у нас есть объект PersonFull, чтобы мы могли заполнить пользовательский интерфейс редактирования. Если объект Person должен быть удален, мы можем легко сделать это с помощью процедур удаления CSLA, сохраняя при этом целостность наших списков на всех виртуальных машинах, которые его слушают.
Итак, я надеюсь, что это имело смысл для всех, и если у кого-то есть другое решение, которое они успешно использовали, или критикуют это, во что бы то ни стало!
Спасибо!
(Перепечатано с: http://forums.lhotka.net/forums/thread/35576.aspx)
