Модели и валидация в нескольких механизмах доставки пользовательского интерфейса

Question

Я работаю с небольшой командой. У нас есть несколько механизмов доставки, часто для одной бизнес-модели, но с разным воздействием. Нам нужна некоторая помощь с нашими моделями совместного использования и проверки эффективности в наших приложениях.

Каков наилучший механизм для создания согласованной проверки для наших моделей как для пользовательского опыта, так и для повторного использования кода в Silverlight 3 (не-RIA Services), ASP.net MVC и WPF?

Мы открыты для использования EF, NHibernate или Linq to Sql для наших моделей доменов. Создание DTO и презентаций / моделей просмотра также приемлемо.

К сожалению, база данных является устаревшей и не соответствует хорошим правилам для ключей.

Мы хотели бы создать единый набор моделей и валидацию (простую валидацию) посетителей или тому подобное, которые можно легко использовать во всех механизмах доставки. Шаблон MVP или MVVM выглядит привлекательно, как и UpdateControls, но мне не удалось найти единый шаблон, который, кажется, работает для всех механизмов.

Удаление ComponentModel из Silverlight 3, похоже, лишает законной силы большинство примеров в Интернете.

Любой совет будет принят с благодарностью.

Answer 1

Ну, я бы лично выбрал Plain Old ClR Objects POCO для бизнес-модели.

using System.ComponentModel.DataAnnotations;

Приведенное выше пространство имен также проверяет ваши объекты. Существует блок проверки корпоративных приложений, но я не знал, как интегрировать его в клиентскую часть Silverlight.

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

Он бы подходил прямо из коробки с NHibernate, но не EF, поскольку это не учитывает POCO. В Linq-to_Sql я верю, но вам нужно либо использовать файлы сопоставления с использованием SQL Metal, либо специальные метаданные для Linq-To_Sql.

Одна из проблем, ну не проблем, а сценариев, с которыми я столкнулся, заключается в том, что я использую WCF для связи между Silverlight и сервером. Это дает вам сгенерированную базу кода для службы, и изменение означает, что любые изменения будут потеряны при следующем обновлении службы.

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

Если вы работаете с .NET в .NET на WCF, вы, конечно, получаете больше функциональных возможностей, но если вам требуется совместимость проверки и возврата ошибок, у меня есть базовый класс Response, который содержит свойства HasErrors и Error []. В настоящее время я делаю следующее:

Silverlight: - Созданный сервисный прокси WCF - ViewModel, который оборачивает классы прокси служб, перехватывая установщики и получатели - Применение проверки на стороне клиента с использованием System.ComponentModel.DataAnnotations

Бизнес-модель: - Я использую POCO с NHibernate - Я использую блок проверки корпоративных приложений - У меня есть базовый класс домена со свойствами HasErrors и Errors

WCF: - Я использую DTO, используя запрос и ответ, т.е.

AddClientResponse AddClient(AddClientRequest request)

Silverlight использует службу WCF, в то время как службы WCF используют хранилище, в котором используется уровень доступа к бизнесу и данным.

С учетом вышесказанного я могу развернуть, скажем, Flex-клиент, и если я не обработаю проверку данных на стороне Flex-клиента, клиент все равно получит ошибки обратно в базовый класс ответа. Затем он должен выполнить проверку на стороне клиента или обработать ошибки, возвращенные с сервера. Конечно же, клиентская сторона сохраняет туда-обратно.

[DataContract]
public class BaseResponse
{
    [DataMember]
    public Error[] Errors { get; set; }
    [DataMember]
    public Boolean HasErrors { get; set; }
}

Надеюсь, это поможет!

Я в поиске знаний, как всегда, лол: -)

Andrew