Здравствуйте, AndrewVK, Вы писали:

IT>>На модели, используемой на сервере.

AVK>Т.е. на сервере все таки модель есть и ее наличие там обязательно? Тогда в чем проблема?

Пока не обязательна. Но для описания разрешений её вполне можно было бы использовать.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndrewVK, Вы писали:

IT>>>На модели, используемой на сервере.

AVK>>Т.е. на сервере все таки модель есть и ее наличие там обязательно? Тогда в чем проблема?

IT>Пока не обязательна. Но для описания разрешений её вполне можно было бы использовать.

А для описания маппинга на сервере?

Здравствуйте, IT, Вы писали:

IT>1. Для задания разрешений на уровне таблиц и полей можно ввести дополнительный атрибут, например, AccessPermissions с соответствующими флагами.
Т.е. описывать роли, юзеров и permissions для них в коде? Что делать, если нужно их поменять? Перекомпиляция и редеплой?

Здравствуйте, IT, Вы писали:

IT>Пока не обязательна.

Т.е. решение, когда структура БД сервера доступна на клиенте считается нормальным?

Здравствуйте, olegkr, Вы писали:

O>Т.е. описывать роли, юзеров и permissions для них в коде? Что делать, если нужно их поменять? Перекомпиляция и редеплой?

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

Здравствуйте, Alex Krasov, Вы писали:

IT>>Пока не обязательна. Но для описания разрешений её вполне можно было бы использовать.
AK>А для описания маппинга на сервере?

Какого маппинга?

Здравствуйте, olegkr, Вы писали:

IT>>1. Для задания разрешений на уровне таблиц и полей можно ввести дополнительный атрибут, например, AccessPermissions с соответствующими флагами.
O>Т.е. описывать роли, юзеров и permissions для них в коде? Что делать, если нужно их поменять? Перекомпиляция и редеплой?

А как добавление новой роли может отразиться на приложении без его модификации?

Здравствуйте, AndrewVK, Вы писали:

AVK>Т.е. решение, когда структура БД сервера доступна на клиенте считается нормальным?

На клиенте вообще-то доступна модель данных сервера, а не структура БД.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndrewVK, Вы писали:

AVK>>Т.е. решение, когда структура БД сервера доступна на клиенте считается нормальным?

IT>На клиенте вообще-то доступна модель данных сервера, а не структура БД.

То есть, с помощью BLT можно сделать следующее?:
— MyTestLinqService предоставляет клиенту service model.
— MyTestLinqServiceClient использует модель данных, сгенерированную, к примеру, через service reference\svcutil, для построения запросов на клиенте.
— BlToolkit mapping attributes доступны только в версии модели данных на сервере. На клиенте нет аттрибутов, описывающих entity mapping\relations.
— при получении MyTestLinqService сервисом запроса от клиента использовать BLT Mapping, описанный серверной моделью данных, для генерации окончательного SQL statement
???

Здравствуйте, Alex Krasov, Вы писали:

AK>То есть, с помощью BLT можно сделать следующее?:
AK>- MyTestLinqService предоставляет клиенту service model.

Клиент сам себе предоставляет модель, зачем ему сервер?

AK>- MyTestLinqServiceClient использует модель данных, сгенерированную, к примеру, через service reference\svcutil, для построения запросов на клиенте.

Как угодно.

AK>- BlToolkit mapping attributes доступны только в версии модели данных на сервере. На клиенте нет аттрибутов, описывающих entity mapping\relations.

Без relations атрибутов на клиенте не будут доступны ассоциации.

AK>- при получении MyTestLinqService сервисом запроса от клиента использовать BLT Mapping, описанный серверной моделью данных, для генерации окончательного SQL statement

Модель на сервере может использоваться для валидации и модификации SqlQuery.

Здравствуйте, IT, Вы писали:

IT>А как добавление новой роли может отразиться на приложении без его модификации?
Берется из конфига.

Здравствуйте, IT, Вы писали:

IT>Без relations атрибутов на клиенте не будут доступны ассоциации.

Так relations как раз в терминах модели описываются. Куда интереснее атрибуты, задающие имена таблиц и полей. А так же sql функции, которые сейчас могут быть ассоциированы с функциями БД.

Здравствуйте, olegkr, Вы писали:

IT>>А как добавление новой роли может отразиться на приложении без его модификации?
O>Берется из конфига.

Взять то без проблем. А что делать с этой ролью? Насколько я понимаю, работа с ролями сводится к следующему коду:

if (user.InRole("MyRole"))
{
}

Если пока нет роли, то нет и подобного кода. Если вводится новая роль, то надо бы это как-то отразить в коде.

Здравствуйте, AndrewVK, Вы писали:

IT>>Без relations атрибутов на клиенте не будут доступны ассоциации.
AVK>Так relations как раз в терминах модели описываются. Куда интереснее атрибуты, задающие имена таблиц и полей. А так же sql функции, которые сейчас могут быть ассоциированы с функциями БД.

Этот маппинг сейчас делается на клиенте. Но нет никаких проблем перемапить всё по своему на сервере. SqlQuery — структура, с которой можно сделать всё, что угодно.

Здравствуйте, IT, Вы писали:

IT>Этот маппинг сейчас делается на клиенте. Но нет никаких проблем перемапить всё по своему на сервере.

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

Здравствуйте, IT, Вы писали:

IT>Взять то без проблем. А что делать с этой ролью?

В конфиге же и использовать. Вот пример из R.Server. Речь, правда, о сервисах, но от БД принципиальных отличий нет:

...

<var name="EveryoneRole">Everyone</var>
<var name="UserRole">Users</var>
<var name="AdministratorRole">Administrators</var>

...

<all-users>
    <role>$(EveryoneRole)</role>
</all-users>
<user name="TestUser" password-hash="yItchBiX2v51zdn4upizLwB9a8M="/>
<user name="TestAdmin" password-hash="AHDRRjD4AdIUOCwt4gG/g7SGR0c=">
    <role>$(UserRole)</role>
    <role>$(AdministratorRole)</role>
</user>

...

<server>
    <allow>$(EveryoneRole)</allow>
</server>
<service name="Svc1">
    <allow>$(UserRole)</allow>
    <allow>$(AdministratorRole)</allow>
</service>
<service name="Svc2">
    <allow>$(UserRole)</allow>
    <method name="Foo">
        <allow>$(AdministratorRole)</allow>
    </method>
</serice>

Только вот в таком варианте, очевидно, никаких деклараций в коде быть не может и непонятно в чем вопрос.

Здравствуйте, AndrewVK, Вы писали:

IT>>Взять то без проблем. А что делать с этой ролью?
AVK>В конфиге же и использовать. Вот пример из R.Server. Речь, правда, о сервисах, но от БД принципиальных отличий нет:

А конфиг деплоить надо?

AVK>Только вот в таком варианте, очевидно, никаких деклараций в коде быть не может и непонятно в чем вопрос.

Вопрос Олега был такой:

А как добавление новой роли может отразиться на приложении без его модификации?

Так вот я и пытаюсь понять как можно новую роль задействовать без модификации приложения.

Здравствуйте, IT, Вы писали:

IT>А конфиг деплоить надо?

Зачем?

IT>Так вот я и пытаюсь понять как можно новую роль задействовать без модификации приложения.

Уже понял? Или еще нет?

Здравствуйте, AndrewVK, Вы писали:

IT>>А конфиг деплоить надо?
AVK>Зачем?

А как? Ты у себя на машине поменял, а на сервере заработало?

IT>>Так вот я и пытаюсь понять как можно новую роль задействовать без модификации приложения.
AVK>Уже понял? Или еще нет?

Ещё нет.

Здравствуйте, IT, Вы писали:

IT>А как? Ты у себя на машине поменял, а на сервере заработало?
Например у нас задеплоить конфиг — на порядок меньший геммор, чем деплоить dll/exe. Во втором случае надо проходить полную процедуру QA/UAT, тестить практически все. Занимает где-то полмесяца минимум. Бюрократия, конечно, но это реальный мир и нам в нем жить.