#breeze #breeze-sharp
#breeze #breeze-sharp
Вопрос:
Мы начали рассматривать возможность использования BreezeSharp, поскольку у нас есть служба ODATA WebAPI, которую мы хотели бы повторно использовать с ASP.NET сайт (без использования javascript, только чистый C #).
К сожалению, мы только что заметили, что, согласно документации, все наши объекты модели теперь должны наследовать от Breeze .Sharp.BaseEntity. Это не для нас, поскольку это означало бы зависимость от Breeze в нашей бизнес-модели. Мы бы предпочли сохранить эту зависимость только от службы WebAPI.
Можем ли мы в любом случае избежать этого? Например, наличие прокси-классов на стороне клиента, когда они не наследуются от BaseEntity ?
Есть мысли по этому поводу?
Ответ №1:
Бриз.Требование Sharp.BaseEntity исключительно на стороне клиента, и причина этого заключается в предоставлении всех функций сохранения, навигации, исправления клавиш, отслеживания изменений и уведомлений и других сервисов, которые делают клиент breeze таким простым в использовании.
Существует интерфейс IEntity, который Breeze.Sharp.BaseEntity реализует, и вы можете реализовать его вместо использования Breeze.Sharp.BaseEntity, однако, это очень нетривиальная задача. Мы рассматриваем возможность предоставления некоторых рекомендаций по этому вопросу позже, если наше сообщество в целом сочтет это желательным.
Мы также планируем выпустить реализацию IEntity AOP, которую можно вводить непосредственно поверх объектов модели POCO, но для этого, вероятно, потребуется PostSharp, а также могут возникнуть проблемы с запуском на некоторых клиентских платформах (Xamarin для Android / IOS). Для этого нет временных рамок, пока мы не почувствуем спрос.
С другой стороны, текущая реализация очень уважительно относится к объектам вашей модели, в вашу модель добавлено только одно свойство EntityAspect вместе с несколькими событиями.
В прошлом мы пробовали подход pure POCO на многих других платформах и библиотеках приложений и обнаружили, что недостатки перевешивают минимальную стоимость базового класса, особенно если учесть, что мы хотели, чтобы эта библиотека работала в любом .СЕТЕВОЙ клиент, включающий Xamarin / Mono.
Комментарии:
1. Я не возражаю против того, чтобы все клиентские сущности наследовали от
BaseEntityin partial class, но это означает, что мне нужно переписать все свойства. Разве нет способа просто перенестиRaisePropertyChangedметод?
Ответ №2:
Если я правильно понимаю, вас беспокоит только то, что вы не хотите ссылаться на breeze# libraries в своей серверной модели. По-видимому, у вас нет проблем с тесной связью ваших клиентских и серверных классов сущностей в том смысле, что они имеют идентичные свойства и, возможно, общие методы. Я не осуждаю; Я просто пытаюсь подтвердить ваши архитектурные решения.
Рассматривали ли вы частичные классы?
Вы определяете частичный класс без breeze в своем проекте серверной бизнес-модели и ссылаетесь на этот источник класса в своем проекте клиентской модели… где вы сохраняете сопутствующий частичный класс с клиентской функциональностью. Этот файл частичного класса клиента определяет базовый класс breeze#.
Пока вы этим занимаетесь, вы можете разделить логику только для сервера в файлах частичных классов, которые находятся в вашем серверном проекте, но не в вашем клиентском проекте.
Такое связывание исходных файлов стало еще проще с VS теперь, когда Microsoft продвигает его в своем видении «универсальных приложений».