Встречал еще такой простой вариант, что на дно душевой кабинки поставить датчик протечки. Использовали в автоматизации, включать музыку когда кто-то моется в душе =)
По первому вопросу, зачем вам сущность для отображения? Обычный SQL и результат в DTO или в массив и на вывод пользователю (ReadModel)
По второму вопросу, нужно больше деталей, т.к. все оч сильно зависит от кейса, но в любом случае другой объект можно передать как аргумент в сам метод, и не нужно никакого DI, но опять же все оч сильно зависит от задачи, и как спроектирован домен.
Я не правильно выразился ) «компонент», я имел ввиду вашу библиотеку. Другими словами, вы с помощью своей схемы отдаете не только формы, но и гриды, а фронт как-то разгребает?
Ну на сколько я понимаю, основа в принципе одинакова. Учет расчета с клиентами согласно оказанных услуг? В принципе и ваша схема, на сколько я понимаю, для того и выложена как основа. Потому думал может есть где почитать, посмотреть на практики других людей в этой сфере.
Спасибо. Было бы интересно и 1-й пункт, хотя бы на уровне SQL, по каждому действию. И последний пункт =)
Какую литературу можно почитать по архитектуре АСР?
В схеме немного не понял. А как к договору привязываются услуги? Не само начисление, а именно какую услугу следует начислять. Например есть «Услуга1», «Услуга2». Должна же быть таблика которая указыват что «Договор 1» использует «Услуга 2», «Договор 2» использует «Услуга 1» и «Услуга 2» одновременно.
Использую Philips xenium x1560, батарея 2900, не противоударный, но есть возможность от него заряжать другие девайсы, есть USB порт специально для этого.
Просто я решал такую же задачу, и автоматическая генерация форм, и по описанию в xml. Но реализовывалось генерацией json, правда тогда мы только знакомились с ExtJS, версия была помоему 3.5. Идея была немного в другом ключе, тоесть мы описываем формы одними обьектами (или автоматически или в xml), а в зависимости какая форма нам нужна ExtJS или обычная HTML выбирали специальный класс для рендеринга єтих обьектов. Вот сейчас собираюсь написать новую версию, учитывая все косяки которые были в предидущей реализации, и новые возможности. И возникла такая идея, есть круд контроллер, обычными 4 методами, и 5-й метод получение описания модели завязаной на этот контроллер, тоесть один метод всегда возвращает описание модели, а все другие гриды и формы используют эту модель, при чем загвоздка в том что отдавать js или json. Пока больше склоняюсь к json т.к. в реализации проще.
Из разряда "Как нарисовать сову":
Рисуем кружочки
Рисуем остаток совы
По поводу ne кмк это аббревиатура от not equal. Встречал много где.
Я сомневаюсь, что стандарт на столько отличный, что за 4 года там не нашли, что исправить или добавить.
Вроде все неплохо, но стандарт вообще не популярный, и кмк не развивается. Даже на сайте https://www.odata.org/blog/ последняя запись 2018 года.
По второму вопросу, нужно больше деталей, т.к. все оч сильно зависит от кейса, но в любом случае другой объект можно передать как аргумент в сам метод, и не нужно никакого DI, но опять же все оч сильно зависит от задачи, и как спроектирован домен.
P.S. Не нашел библиотеки у вас в репозитории
Какую литературу можно почитать по архитектуре АСР?