Сообщение Re[5]: Вижу: DRY, копипаста от 10.10.2017 8:34
Изменено 10.10.2017 15:17 igor-booch
Re[5]: Вижу: DRY, копипаста
S>5. Если вы измените какое-либо поле в контракте или добавите новое -- компилятор сразу же сообщит об этом, т.е. не забудете исправить во всех слоях.
Это весомое преимущество. Конечно я за интерфейсы. Какие еще Вы видите профиты от интерфейсов в рассматриваемом сценарии? Я вижу следующее преимущество: можно навесить логику на интерфейс IOrder (например, в виде экстеншен методов), поместить её в сборку вместе интерфейсом IOrder и использовать эту логику в десктопе и веб приложении (десктоп и веб приложение ссылаются на сборку с интерфейсом).
В случае если с десктопа и с веб приложения был бы допустим прямой доступ к БД, я бы сделал проще.
Слой доступа к данным (имеющий прямой доступ к БД) реализуем в сборке. Десктоп и веб приложение просто ссылаются на эту сборку. Если веб приложению понадобятся доп. свойства у Order в сборке веб приложения создаем наследника WebOrder : Order. Аналогично для десктопа. В этом случае интерфейс IOrder не нужен. Вернее он может понадобиться, но только как часть бизнес модели, но не как технический интерфейс для обеспечения инфраструктуры слоёв (скелета бизнес объектов, как Вы сказали). Если кому-то понадобился непрямой доступ к БД (через сервис), оборачиваем ту же сборку доступа к данным в сервис, и тогда технический интерфейсы для обеспечения инфраструктуры слоёв становятся нужны. Но в этом случае логику на инфраструктурный интерфейс IOrder уже не навесишь (как я выше написал), так как она уже в классе Order присутствует. Но я сторонник прямого доступа к БД с десктопа (с веб приложения тем более). Да, надо поработать над безопасностью, правами доступа пользователей на уровне БД, SSL соединением клиента С БД, но дело того стоит. Не надо создавать сервис доступа к БД, только для того чтобы не возиться с её настройками безопасности.
S>3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
Несколько различных реализаций IOrderService кроме тестирования может ещё для чего-то понадобиться?
Это весомое преимущество. Конечно я за интерфейсы. Какие еще Вы видите профиты от интерфейсов в рассматриваемом сценарии? Я вижу следующее преимущество: можно навесить логику на интерфейс IOrder (например, в виде экстеншен методов), поместить её в сборку вместе интерфейсом IOrder и использовать эту логику в десктопе и веб приложении (десктоп и веб приложение ссылаются на сборку с интерфейсом).
В случае если с десктопа и с веб приложения был бы допустим прямой доступ к БД, я бы сделал проще.
Слой доступа к данным (имеющий прямой доступ к БД) реализуем в сборке. Десктоп и веб приложение просто ссылаются на эту сборку. Если веб приложению понадобятся доп. свойства у Order в сборке веб приложения создаем наследника WebOrder : Order. Аналогично для десктопа. В этом случае интерфейс IOrder не нужен. Вернее он может понадобиться, но только как часть бизнес модели, но не как технический интерфейс для обеспечения инфраструктуры слоёв (скелета бизнес объектов, как Вы сказали). Если кому-то понадобился непрямой доступ к БД (через сервис), оборачиваем ту же сборку доступа к данным в сервис, и тогда технический интерфейсы для обеспечения инфраструктуры слоёв становятся нужны. Но в этом случае логику на инфраструктурный интерфейс IOrder уже не навесишь (как я выше написал), так как она уже в классе Order присутствует. Но я сторонник прямого доступа к БД с десктопа (с веб приложения тем более). Да, надо поработать над безопасностью, правами доступа пользователей на уровне БД, SSL соединением клиента С БД, но дело того стоит. Не надо создавать сервис доступа к БД, только для того чтобы не возиться с её настройками безопасности.
S>3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
Несколько различных реализаций IOrderService кроме тестирования может ещё для чего-то понадобиться?
Re[5]: Вижу: DRY, копипаста
S>5. Если вы измените какое-либо поле в контракте или добавите новое -- компилятор сразу же сообщит об этом, т.е. не забудете исправить во всех слоях.
Это весомое преимущество. Конечно я за интерфейсы. Какие еще Вы видите профиты от интерфейсов в рассматриваемом сценарии? Я вижу следующее преимущество: можно навесить логику на интерфейс IOrder (например, в виде экстеншен методов), поместить её в сборку вместе интерфейсом IOrder и использовать эту логику в десктопе и веб приложении (десктоп и веб приложение ссылаются на сборку с интерфейсом).
В случае если с десктопа и с веб приложения был бы допустим прямой доступ к БД, я бы сделал проще.
Слой доступа к данным (имеющий прямой доступ к БД) реализуем в сборке. Десктоп и веб приложение просто ссылаются на эту сборку.
Если веб приложению понадобятся доп. свойства у Order,
в сборке веб приложения создаем наследника WebOrder : Order. Аналогично для десктопа.
В этом случае интерфейс IOrder не нужен. Вернее он может понадобиться, но только как часть бизнес модели, но не как технический интерфейс для обеспечения инфраструктуры слоёв (скелета бизнес объектов, как Вы сказали).
Если кому-то понадобился непрямой доступ к БД (через сервис), оборачиваем ту же сборку доступа к данным в сервис, и тогда технический интерфейсы для обеспечения инфраструктуры слоёв становятся нужны. Но в этом случае логику на инфраструктурный интерфейс IOrder уже не навесишь (как я выше написал), так как она уже в классе Order присутствует.
Но я сторонник прямого доступа к БД с десктопа (с веб приложения тем более). Да, надо поработать над безопасностью, правами доступа пользователей на уровне БД, SSL соединением клиента С БД, но дело того стоит. Не надо создавать сервис доступа к БД, только для того чтобы не возиться с её настройками безопасности.
S>3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
Несколько различных реализаций IOrderService кроме тестирования может ещё для чего-то понадобиться?
Это весомое преимущество. Конечно я за интерфейсы. Какие еще Вы видите профиты от интерфейсов в рассматриваемом сценарии? Я вижу следующее преимущество: можно навесить логику на интерфейс IOrder (например, в виде экстеншен методов), поместить её в сборку вместе интерфейсом IOrder и использовать эту логику в десктопе и веб приложении (десктоп и веб приложение ссылаются на сборку с интерфейсом).
В случае если с десктопа и с веб приложения был бы допустим прямой доступ к БД, я бы сделал проще.
Слой доступа к данным (имеющий прямой доступ к БД) реализуем в сборке. Десктоп и веб приложение просто ссылаются на эту сборку.
Если веб приложению понадобятся доп. свойства у Order,
в сборке веб приложения создаем наследника WebOrder : Order. Аналогично для десктопа.
В этом случае интерфейс IOrder не нужен. Вернее он может понадобиться, но только как часть бизнес модели, но не как технический интерфейс для обеспечения инфраструктуры слоёв (скелета бизнес объектов, как Вы сказали).
Если кому-то понадобился непрямой доступ к БД (через сервис), оборачиваем ту же сборку доступа к данным в сервис, и тогда технический интерфейсы для обеспечения инфраструктуры слоёв становятся нужны. Но в этом случае логику на инфраструктурный интерфейс IOrder уже не навесишь (как я выше написал), так как она уже в классе Order присутствует.
Но я сторонник прямого доступа к БД с десктопа (с веб приложения тем более). Да, надо поработать над безопасностью, правами доступа пользователей на уровне БД, SSL соединением клиента С БД, но дело того стоит. Не надо создавать сервис доступа к БД, только для того чтобы не возиться с её настройками безопасности.
S>3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
Несколько различных реализаций IOrderService кроме тестирования может ещё для чего-то понадобиться?