Сообщение Re[4]: Вижу: DRY, копипаста от 10.10.2017 3:00
Изменено 10.10.2017 3:51 Shmj
Re[4]: Вижу: DRY, копипаста
Здравствуйте, igor-booch, Вы писали:
IB>Я не уверен, что правильно понимаю Вашу технологию интерфейсов. Допустим есть слой доступа к данным. Есть web приложение и десктоп приложение. Web приложение и десктоп приложение умеют сохранять заказ, используя при этом слой доступа к данным. Какие где будут классы и интерфейсы?
1. Выделяете слой сервисов, реализация которых не зависит от GUI. Создаете контракты для каждого сервиса. К примеру, будет интерфейс IOrderService. А в нем метод CreateOrder(INewOrder order). Так вот INewOrder -- тоже интерфейс, но уже для бизнес-объекта.
2. В реализации сервиса IOrderService делаете класс OrderService, который реализует метод CreateOrder. А так же в реализации сервисов делаете класс бизнес-объекта NewOrder, который реализует INewOrder (делается одной кнопкой). И у этого класса уже проставляете нужные вам поля.
3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
4. Web-приложение делает свой класс-реализацию INewOrder. Причем может добавлять доп. поля и доп. атрибуты, которые нужны ему. Соответственно десктоп-приложение делает то же самое -- свои доп. поля и атрибуты.
5. Если вы измените какое-либо поле в контракте или добавите новое -- компилятор сразу же сообщит об этом, т.е. не забудете исправить во всех слоях.
IB>Я не уверен, что правильно понимаю Вашу технологию интерфейсов. Допустим есть слой доступа к данным. Есть web приложение и десктоп приложение. Web приложение и десктоп приложение умеют сохранять заказ, используя при этом слой доступа к данным. Какие где будут классы и интерфейсы?
1. Выделяете слой сервисов, реализация которых не зависит от GUI. Создаете контракты для каждого сервиса. К примеру, будет интерфейс IOrderService. А в нем метод CreateOrder(INewOrder order). Так вот INewOrder -- тоже интерфейс, но уже для бизнес-объекта.
2. В реализации сервиса IOrderService делаете класс OrderService, который реализует метод CreateOrder. А так же в реализации сервисов делаете класс бизнес-объекта NewOrder, который реализует INewOrder (делается одной кнопкой). И у этого класса уже проставляете нужные вам поля.
3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
4. Web-приложение делает свой класс-реализацию INewOrder. Причем может добавлять доп. поля и доп. атрибуты, которые нужны ему. Соответственно десктоп-приложение делает то же самое -- свои доп. поля и атрибуты.
5. Если вы измените какое-либо поле в контракте или добавите новое -- компилятор сразу же сообщит об этом, т.е. не забудете исправить во всех слоях.
Re[4]: Вижу: DRY, копипаста
Здравствуйте, igor-booch, Вы писали:
IB>Я не уверен, что правильно понимаю Вашу технологию интерфейсов. Допустим есть слой доступа к данным. Есть web приложение и десктоп приложение. Web приложение и десктоп приложение умеют сохранять заказ, используя при этом слой доступа к данным. Какие где будут классы и интерфейсы?
1. Выделяете слой сервисов, реализация которых не зависит от GUI. Создаете контракты для каждого сервиса. К примеру, будет интерфейс IOrderService. А в нем метод CreateOrder(IOrder order). Так вот IOrder -- тоже интерфейс, но уже для бизнес-объекта.
2. В реализации сервиса IOrderService делаете класс OrderService, который реализует метод CreateOrder. А так же в реализации сервисов делаете класс бизнес-объекта Order, который реализует IOrder (делается одной кнопкой). И у этого класса уже проставляете нужные вам поля.
3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
4. Web-приложение делает свой класс-реализацию IOrder. Причем может добавлять доп. поля и доп. атрибуты, которые нужны ему. Соответственно десктоп-приложение делает то же самое -- свои доп. поля и атрибуты.
5. Если вы измените какое-либо поле в контракте или добавите новое -- компилятор сразу же сообщит об этом, т.е. не забудете исправить во всех слоях.
IB>Я не уверен, что правильно понимаю Вашу технологию интерфейсов. Допустим есть слой доступа к данным. Есть web приложение и десктоп приложение. Web приложение и десктоп приложение умеют сохранять заказ, используя при этом слой доступа к данным. Какие где будут классы и интерфейсы?
1. Выделяете слой сервисов, реализация которых не зависит от GUI. Создаете контракты для каждого сервиса. К примеру, будет интерфейс IOrderService. А в нем метод CreateOrder(IOrder order). Так вот IOrder -- тоже интерфейс, но уже для бизнес-объекта.
2. В реализации сервиса IOrderService делаете класс OrderService, который реализует метод CreateOrder. А так же в реализации сервисов делаете класс бизнес-объекта Order, который реализует IOrder (делается одной кнопкой). И у этого класса уже проставляете нужные вам поля.
3. Web-приложение и десктоп-приложение работают не с сервисом OrderService, а с контрактами IOrderService. Конкретную реализацию подключаете с помощью IoC (есть готовые либы типа Unity и пр.).
4. Web-приложение делает свой класс-реализацию IOrder. Причем может добавлять доп. поля и доп. атрибуты, которые нужны ему. Соответственно десктоп-приложение делает то же самое -- свои доп. поля и атрибуты.
5. Если вы измените какое-либо поле в контракте или добавите новое -- компилятор сразу же сообщит об этом, т.е. не забудете исправить во всех слоях.