Удаленные методы, централизованное управление удаленным доступом

Question

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

Например, есть модуль «Предложение». Модуль предложений состоит из 4 проектов: Действие, Сообщение, Сущность и Запрос. Проект Query обычно содержит классы, которые содержат удаленные методы.

Первый вопрос: как я могу разработать свой сервер таким образом, чтобы он управлял всеми транзакциями, запросами централизованно. Я имею в виду, что все запросы должны быть направлены от этого центрального управляющего класса к запрашиваемому модулю и его удаленному методу. Мне нужны ваши идеи.

Второе: допустим, что в моем модуле Offer класс ProductQuery проекта Query имеет 10 методов, но 5 из них являются удаленными. Класс CustomerQuery имеет 15 методов, 3 из которых являются удаленными методами. Я хочу получить все удаленные методы в одном проекте запроса (например, в проекте Query от OfferModule или в проекте Query для модуля Accounting) в одной сборке для удаленного взаимодействия. Например, в одной сборке OfferQuery.

Мне нужна твоя помощь. Спасибо!

Answer 1

Я оставлю ваш первый вопрос без ответа, потому что на него нельзя ответить в его нынешней форме.

---

Мое понимание вашего второго вопроса:

Во-первых, позвольте мне попытаться понять базовую схему архитектуры вашего сервера:

  +--------+  1     1..n  +--------+  1    1..n  +---------+
  | Server |<>------------| Module |<>-----------| Project |
  +--------+              +--------+             +---------+

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

Более конкретно, у вас, кажется, есть эта иерархия модулей, проектов и классов:

Server
|
+---- Accounting (module)
|     ¦
|     ? (projects)
|
+---- Offer (module)
¦     |
?     +---- Action (project)
      |
      +---- Message (project)
      |
      +---- Entity (project)
      |
      +---- Query (project)
            |
            +---- ProductQuery (class)
            |
            +---- CustomerQuery (class)
            ¦
            ?

И если я вас правильно понимаю, вы теперь хотите собрать все "удаленные" методы запроса, например, ProductQuery и CustomerQuery внутри общего OfferQuery класса ... это правильно?

---

Предлагаемое направление к решению вашего второго вопроса:

Теперь, учитывая, что вы не предоставили подробных сведений о технологиях и инфраструктурах, которые вы используете, я также буду немного расплывчатым:

Я думаю, что вы пытаетесь сделать, не очень хороший подход. Зачем? Потому что вы собираетесь поместить совершенно не связанные вещи в один класс, основываясь на том, что все они являются «запросными» методами. Но они запрашивают совершенно разные вещи: например, Offers, Products, Customers. Это не очень хороший объектно-ориентированный дизайн, потому что он не "доменно-ориентированный". Он ориентирован на запросы.

Я думаю, вы бы хорошо разработали модель чистого объекта (домена). Разработайте классы вокруг логических объектов в вашей системе (например, уже упомянутые предложения, продукты, счета, клиенты и т. Д.). Держите соответствующие классы полностью свободными от методов запросов.

Теперь, куда отправляются запросы? Вы можете посмотреть на объектно-реляционные модели сопоставления (OR / M) для этой задачи. Hibernate (или с .NET, NHibernate) или Microsoft Entity Framework для .NET являются хорошими вариантами. Они отобразят вашу модель домена в реляционную базу данных и сделают все создание, запрос, обновление и удаление в БД для вас.