Вот есть у меня слой модели, содержащий бизнес-логику. Есть слой клиента, содержащий логику интерфейса для десктопа. Может быть ещё слой клиента, содержащий логику интерфейса для веба или телефона. Все эти слои - в отдельных сборках, т. к. фактически представляют из себя: клиенсткие слои - это клиентские приложения с UI и т. п., а слой бизнес-логики - DLL, чтобы можно было запустить его на любом клиенстком устройстве, если понадобиться, или отдать службе на сервере, или ещё что-нибудь.

Есть набор данных, которыми будут обмениваться слои. Он должен быть общим для них. Какой лучший способ это сделать?

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

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

skyANAНемоКэп42Вот есть у меня слой модели, содержащий бизнес-логику. Есть слой клиента, содержащий логику интерфейса для десктопа. Может быть ещё слой клиента, содержащий логику интерфейса для веба или телефона. Все эти слои - в отдельных сборках, т. к. фактически представляют из себя: клиенсткие слои - это клиентские приложения с UI и т. п., а слой бизнес-логики - DLL, чтобы можно было запустить его на любом клиенстком устройстве, если понадобиться, или отдать службе на сервере, или ещё что-нибудь.

Есть набор данных, которыми будут обмениваться слои. Он должен быть общим для них. Какой лучший способ это сделать?

Я пока придумал сделать отдельную сборку (DLL), в которой будет описан класс этих общих данных и на которую нужно сослаться (через references) каждому проекту других слоёв.Обычно создаётся проект Business.DomainModel, что собирается в MyApplication.Business.DomainModel.dll и туда вынесятся сущности предметной области.

Какой ещё набор данных Вам нужен? DTO объекты сериализуемые в XML/JSON? Для каких слоёв они будут общими?
Этот "общий набор данных" - это то, что должна отдавать доменная модель клиентам. Но сейчас я подумал и решил, что для разных клиентов это будут разные наборы данных. Хотя бы разграниченные по уровню доступа: разработчикам всё подробно с логами на каждое действие, другим разработчикам - подробно без логов, а клиентам - неподробно и тоже без логов. Но при этом генерить эти разные "ответы" должна серверная часть. Как это лучше сделать?

Я так понимаю, что надо создать сборку с разными типами результатов - по типу на каждый тип клиента. Так?

НемоКэп42skyANAпропущено...
Обычно создаётся проект Business.DomainModel, что собирается в MyApplication.Business.DomainModel.dll и туда вынесятся сущности предметной области.

Какой ещё набор данных Вам нужен? DTO объекты сериализуемые в XML/JSON? Для каких слоёв они будут общими?
Этот "общий набор данных" - это то, что должна отдавать доменная модель клиентам. Но сейчас я подумал и решил, что для разных клиентов это будут разные наборы данных. Хотя бы разграниченные по уровню доступа: разработчикам всё подробно с логами на каждое действие, другим разработчикам - подробно без логов, а клиентам - неподробно и тоже без логов. Но при этом генерить эти разные "ответы" должна серверная часть. Как это лучше сделать?

Я так понимаю, что надо создать сборку с разными типами результатов - по типу на каждый тип клиента. Так?
Серверное приложение устроено так, что оно получает от клиента данные и делает по ним расчёт. Наиболее полные результаты расчёта хранятся на сервере, а разные их (результатов) обрезанные комбинации надо пересылать клиентам в соответствии с типом этих клиентов.

НемоКэп42НемоКэп42пропущено...

Этот "общий набор данных" - это то, что должна отдавать доменная модель клиентам. Но сейчас я подумал и решил, что для разных клиентов это будут разные наборы данных. Хотя бы разграниченные по уровню доступа: разработчикам всё подробно с логами на каждое действие, другим разработчикам - подробно без логов, а клиентам - неподробно и тоже без логов. Но при этом генерить эти разные "ответы" должна серверная часть. Как это лучше сделать?

Я так понимаю, что надо создать сборку с разными типами результатов - по типу на каждый тип клиента. Так?
Серверное приложение устроено так, что оно получает от клиента данные и делает по ним расчёт. Наиболее полные результаты расчёта хранятся на сервере, а разные их (результатов) обрезанные комбинации надо пересылать клиентам в соответствии с типом этих клиентов.
Ну, под серверным приложением я тут как раз и понимаю сборку доменной логики. То, что она работает на сервере - частный случай.

Т. е. результаты вроде бы соотносятся с клиентами, но генериться должны на сервере. При этом доменной логике всё равно на результаты - она не должна зависеть от того, кому она отдаёт эти результаты. Она только делает расчёте в предметной области. Поэтому я хочу вынести набор типов с результатами в отдельную сборку, чтобы эти типы результатов не зависели ни от клиентских сборок, ни от сборки доменной логики.

Я немного запутался. Сейчас постараюсь привести всё в порядок.

Клиентский слой может передавать данные для расчёта. Доменная логика делает расчёт по этим данным. Результаты расчёта доменная логика хранит у себя (в ОЗУ или пишет в БД - неважно). Но часть расчётов должна отдать клиенту. В зависимости от типа клиента, это будут разные части результатов, включая вариант "все результаты полностью" (но это для разработчиков для анализов в основном).

Результаты представляют собой коллекции данных разных типов (int, double, string), просто данные разных типов (int, double, string).

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

Но, и клиенты, и эта служба должны знать, что за набор результатов они получат. Эти разные наборы результатов будут представлять из себя классы результатов - типа ClientResults, DeveloperResults и т. п.

Чтобы и клиентские приложения, и служба знали про эти классы результатов, но не знали про логику друг друга (общение через сериализацию классов результатов - как это WCF делает), нужно эти классы результатов вынести в отдельную сборку и сделать ссылку на эту сборку из службы и из клиентских приложений.

Итого:

- отдельная сборка для доменной логики (ДЛ);
- отдельные сборки для каждого типа клиентов (К);
- отдельная сборка для классов результатов (Р) - соответствующих типам клиентов;
- отдельная сборка для службы (С).

Вот как я вижу отношения между этими сборками: (см. рисунок)

Т. е. результаты и доменная логика автономны и ни от кого не зависят.

Здесь не отражено, как доменная логика хранит результаты - это не "Р", а некоторый свой тип данных, хранящий наиболее полные результаты. А "Р" - это сборка с типами "обрезанных" результатов для разных типов клиентов.

НемоКэп42Но часть расчётов должна отдать клиенту.
Не расчётов, а результатов расчёта, конечно же.

Добавил отношение сборок к серверной и клиентской частям.

skyANAНемоКэп42, зачем Р отделять от К ?
Классы Р будут формироваться в службе, затем сериализовываться и передаваться клиентам. Клиент десериализует эти данные. Т. е. и служба, и клиенты должны знать, как десериализовывать такие данные - т. е. должны иметь код классов Р.

Возможно, чтобы разные клиенты не знали об устройстве данных для других клиентов, нужно каждый тип результата выделить в отдельную сборку, соответствующую типу клиента - Р1, Р2 и т. д.?

НемоКэп42skyANAНемоКэп42, зачем Р отделять от К ?
Классы Р будут формироваться в службе, затем сериализовываться и передаваться клиентам. Клиент десериализует эти данные. Т. е. и служба, и клиенты должны знать, как десериализовывать такие данные - т. е. должны иметь код классов Р.

Возможно, чтобы разные клиенты не знали об устройстве данных для других клиентов, нужно каждый тип результата выделить в отдельную сборку, соответствующую типу клиента - Р1, Р2 и т. д.?

Если я помещю Р1 в К1, Р2 в К2 и т. д., то как мне сослаться на Р из С? Для этого надо будет сделать ссылку из С на К, а К уже имеет ссылку на С. А циклические ссылки между проектами делать нельзя.

skyANAвообщем понятно. ИМХО нормально:НемоКэп42- отдельная сборка для доменной логики (ДЛ);
- отдельные сборки для каждого типа клиентов (К);
- отдельная сборка для классов результатов (Р) - соответствующих типам клиентов;
- отдельная сборка для службы (С).
действуйте
А если с учётом этого

авторВозможно, чтобы разные клиенты не знали об устройстве данных для других клиентов, нужно каждый тип результата выделить в отдельную сборку, соответствующую типу клиента - Р1, Р2 и т. д.?

у меня получается вот это: (см. рисунок)

это нормально, исходя из моих требований? Просто получается, что сборок результатов будет по числу клиентов - не много ли сборок?..


Хотя, глядя на некоторые программы, как в них сотни ДЛЛ устанавливаются, у меня ещё всё нормально.

(хорошо иметь планшет на Винде со стилусом )

Тут ещё надо уточнить, что число Р в общем случае не равно числу К. Число К зависит от числа типов приложений, а число Р - от числа типов аккаунтов.