VS 2005, Framework 2.0

Работаю над двузвенной СУБД

Общее решение выглядит примерно так:
Client клиентская компонента (WindowsApplication, формы, сериализуемые объекты которыми оперирует приложение)
DAL — data access logic серверная компонента (WindowsService, имеет доступ к БД, возвращает клиенту полученные из БД сериализуемые объекты)
MS SQL (собственно БД)

Сериализуемый объект (СО) это набор скалярных полей и таблиц

class serObj
{
int ID;
string name;
...
DataTable Moves;
...
}

DAL реадизует интерфейс через который к нему обращается клиент

class DAL:MarshalByRef, IDAL
{
void Read(ref serObj)
{serObj.Moves = sql.ReadMove(....); serObj.Moves.Constraints.Add(new UniqueConstraint(...)); ...}
}

На таблицы содержащиеся в СО, наложены ограничения. Так как клиент "тонкий", то вся логика работы с СО заложена в DAL, в том числе и ограничения.
Если в БД все хорошо, то клиент получает готовую, заполненную таблицу с ограничениями и работает с ней не нарушая логики организации данных.

Плохо становится когда в БД, содержаться записи не удовлетворяющие этим ограничениям (в моем случае при переносе из другой БД).
В моем случае ситуация развивалась так:

DAL получает таблицу с ошибочными сведениями и пытается прикрутить к ней constraint (например UniqueConstraint), возникает исключение, если его обработать и все таки вернуть таблицу клиенту, то исключение тут же возникает в клиенте, при этом исключение не содержит никакой полезной информации об ограничении.

Повозился с Contsraint и DataTable, и понял что при такой схеме либо придется возвращать данные без ограничения (т.е их вряд ли исправят), либо возвращать неполные\пустые, но с ограничением.

Подумал и переделал DAL следующим образом добавил событие которое отправляется в догонку данным и служит сигналом о том что данные не удовлетворяют наложенным сервером ограничениям и их необходимо исправить.

class DAL:MarshalByRef, IDAL
{
event NeedConstraintHandler NeedConstraint;

void Read(ref serObj)
{
   serObj.Moves = sql.ReadMove(....); 
   try { serObj.Moves.Constraints.Add(new UniqueConstraint(...)); } 
   catch (Exception exc) {NeedConstraint(NeedConstraintEventArgs args); }
   ...
}

Когда переделал понял, что событие происходит раньше чем возвращаются сами данные.
Т.е СО еще в обработке, а клиент уже получил сигнал о том, что он (СО) неверен.
Эту ситуацию конечно можно разрешить, генерирую событие из отдельного потока и синхронировав этот поток с потоком обрабатывающим СО.

Оглядел все свое "творчество" и понял, что решение сложное и интуитивно мне кажется неоправданно сложное. Мне кажется, что где-то я прокололся и все должно решаться проще. А вот как понять не могу.

Собственно вопрос: Как организовать обмен DataTable с ограничениями между двумя удаленными компонентами, таким образом чтобы они могли обмениваться данными которые не удовлетворяют этим ограничениям?

PS Есть конечно вариант создать для каждого поля-таблицы вспомогательное поле содеражащее исходные данные для ограничения
(само ограничение по-моему не сериализуемо) и собирать и прикручивать на клиенте. НО во первых это требует жесткого контроля за кодом, т.е после каждого обращения к DAL, необходимо проверить не надо ли чего прикрутить к полученным таблицам. Второе НО субъективное на мой взгляд этот вариант не очень клиентский, не очень "тонкий клиент" получается.

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

N>VS 2005, Framework 2.0

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

N>Собственно вопрос: Как организовать обмен DataTable с ограничениями между двумя удаленными компонентами, таким образом чтобы они могли обмениваться данными которые не удовлетворяют этим ограничениям?
А клиент вообще может отправить серверу некорректные данные? Если нет, тогда все проблемы надо решать на сервере.

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

Жуткая каша, однако.
"Двухзвенная СУБД" , "тонкий клиент" на Winforms, сериализуемые объекты с DataTable-ми внутри.
Попробуйте ответить на простые вопросы:
— почему клиент тонкий? Какие функциональные требования к нему предъявляются как к "тонкому клиенту", null deployment, работа под различными ОС, работа over Internet, слабые клиентские машины? Для чего тонкий клиент?
— зачем вам средний слой, он же DAL, он же Windows service? Почему не разместить этот функционал на клиенте? Вы вообще в курсе, для чего обычно используют средний слой? Какие этим решаются задачи? Почему выбран Windows service в качестве среднего слоя? У среднего слоя основная задача — разделять дефицитные ресурсы (соединения с БД, сетевые соединения, память) между клиентами. А для этого средний слой должен очень эффективно работать с ресурсами в многопоточной среде. Выбор windows service означает, что всей этой работой вы намерены заниматься самостоятельно. Справитесь? Может лучше IIS?
— какие ограничения на данные? отчего происходит так, что ограничения есть и в тоже время данные не соответствуют этим ограничениям?
Теперь по существу вопроса о констрейнтах.
Действительно, иногда встречаются задачи в которых существуют логические ограничения на структуру данных и в тоже время нужна возможность хранить данные не соответствующие эти ограничениям. Например, графический редактор диаграм хранит данные в виде связного графа объектов и существуют достаточно сложные правила и ограничения на его структуру. Если все правила проверять online, редактирование диаграмы становится неудобным. В таком случае правила и ограничения отделяют от данных в отдельный класс валидатор. Валидатор получает даные, проверяет все правила и ограничения и выдает вердикт: валидные данные или нет. В этом случае хранить можно, как валидные данные, так и невалидные.

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

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

S>Жуткая каша, однако.
S>"Двухзвенная СУБД" , "тонкий клиент" на Winforms, сериализуемые объекты с DataTable-ми внутри.
S>Попробуйте ответить на простые вопросы:
S> — почему клиент тонкий? Какие функциональные требования к нему предъявляются как к "тонкому клиенту", null deployment, работа под различными ОС, работа over Internet, слабые клиентские машины? Для чего тонкий клиент?

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

S> — зачем вам средний слой, он же DAL, он же Windows service? Почему не разместить этот функционал на клиенте? Вы вообще в курсе, для чего обычно используют средний слой? Какие этим решаются задачи? Почему выбран Windows service в качестве среднего слоя? У среднего слоя основная задача — разделять дефицитные ресурсы (соединения с БД, сетевые соединения, память) между клиентами. А для этого средний слой должен очень эффективно работать с ресурсами в многопоточной среде. Выбор windows service означает, что всей этой работой вы намерены заниматься самостоятельно. Справитесь? Может лучше IIS?

Средний слой, помимо организации данных с уровня SQL на уровень приложения, организует безопасность(доступ). Вообще решение не претендует на 100% оптимальность. По поводу организации многозвенных систем, функциональности отдельных звеньев, правил организации взаимодествия между ними с удовольствием бы прочитал что-нибудь хорошее и упорядоченное — какие-то основные подходы к этим вопросам, а не отдельные решения.

S> — какие ограничения на данные? отчего происходит так, что ограничения есть и в тоже время данные не соответствуют этим ограничениям?

N> Плохо становится когда в БД, содержаться записи не удовлетворяющие этим ограничениям (в моем случае при переносе из другой БД).
Исправить эту ситуацию я конечно могу и на этапе переноса, но в таком случае повторное возникновение неверных данных в БД будет решаться только техподдержкой\БД-админстратором

S>Теперь по существу вопроса о констрейнтах.
S>Действительно, иногда встречаются задачи в которых существуют логические ограничения на структуру данных и в тоже время нужна возможность хранить данные не соответствующие эти ограничениям. Например, графический редактор диаграм хранит данные в виде связного графа объектов и существуют достаточно сложные правила и ограничения на его структуру. Если все правила проверять online, редактирование диаграмы становится неудобным. В таком случае правила и ограничения отделяют от данных в отдельный класс валидатор. Валидатор получает даные, проверяет все правила и ограничения и выдает вердикт: валидные данные или нет. В этом случае хранить можно, как валидные данные, так и невалидные.

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

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

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

N>>VS 2005, Framework 2.0

N>>Плохо становится когда в БД, содержаться записи не удовлетворяющие этим ограничениям (в моем случае при переносе из другой БД).
G>А нельзя этот вопрос на уровне БД решить? Нпример не выбирать повторяющиеся записи.

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

N>>Собственно вопрос: Как организовать обмен DataTable с ограничениями между двумя удаленными компонентами, таким образом чтобы они могли обмениваться данными которые не удовлетворяют этим ограничениям?
G>А клиент вообще может отправить серверу некорректные данные? Если нет, тогда все проблемы надо решать на сервере.

Ограничения нарушить клиент не может (у меня не получается создать из интерфейса такую ситуацию), но может отправить серверу данные неверные по другим критериям (например записи о приеме на работу\переводе\увольнении, в неправильном хронологическом порядке), тогда сервер примет их, проверит, откажеться записать и отправит предупреждение клиенту. Т.е клиент не может внести в БД неверные данные (в ходе моего тестирования не получилось), НО неверные данные которые попали в БД (сейчас при переносе из другой БД) либо не попадают к клиенту либо попадают без необходимых ограничений либо приходится городить весь этот огород описанный в исходном посте.

Ситуация такова, что есть данные которые не соответствуют ограничениям, но какими они должны быть алгоритм не знает. Т.е ошибку может исправить только пользователь, для этого надо его предупредить о том, что "есть такие-то ограничения и вот эти данные им не соответствуют".

Вашу фразу "все проблемы надо решать на сервере", я наверное неправильно понимаю т.к. в моей трактовке получается что СУБД сама исправляет ошибки пользователей (введенные в предыдущей БД), поэтому остается только научить ее самой вводить новые данные и выбросить пользователей вместе с клиентской частью за ненадобностью.

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

S> У среднего слоя основная задача — разделять дефицитные ресурсы (соединения с БД, сетевые соединения, память) между клиентами.
А если в среднем слое разместить бизнес-логику? ИМХО он для этого очень хорошо подходит. А вот использовать его в основном для разделения дефицитных ресурсов типа соединения с БД я лично не вижу большого смысла. С таким же успехом можно просто использовать пул подключений на сервере БД и открывать коннекшин к базе на клиенте только когда он реально нужен.
S> А для этого средний слой должен очень эффективно работать с ресурсами в многопоточной среде. Выбор windows service означает, что всей этой работой вы намерены заниматься самостоятельно. Справитесь? Может лучше IIS?
А, например, какой-такой работой? Если там ремоутинг, то все запросы приходят в отдельных потоках, основная задача при этом сводится к синхронизации доступа к общим ресурсам. Как IIS в этом поможет?

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

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

S>> У среднего слоя основная задача — разделять дефицитные ресурсы (соединения с БД, сетевые соединения, память) между клиентами.
H>А если в среднем слое разместить бизнес-логику? ИМХО он для этого очень хорошо подходит. А вот использовать его в основном для разделения дефицитных ресурсов типа соединения с БД я лично не вижу большого смысла. С таким же успехом можно просто использовать пул подключений на сервере БД и открывать коннекшин к базе на клиенте только когда он реально нужен.
Это кстати распространенное заблуждение, о том что средний слой был придуман только для размещения бизнес логики
S>> А для этого средний слой должен очень эффективно работать с ресурсами в многопоточной среде. Выбор windows service означает, что всей этой работой вы намерены заниматься самостоятельно. Справитесь? Может лучше IIS?
H>А, например, какой-такой работой? Если там ремоутинг, то все запросы приходят в отдельных потоках, основная задача при этом сводится к синхронизации доступа к общим ресурсам. Как IIS в этом поможет?
В чем поможет IIS?
— встроенная аутентификация клиентов и защищенный канал. Ни того ни другого нет в голом ремотинге.
— поддержка масштабирования, IIS способен запускать при необходимости несколько пулов для вашего приложения и распределять между запросы между ними
— лучшая изоляция процессов. Если ваш сервер крив до не возможности, под IIS у него меньше шансов завалить всю систему.
— встроенный recycling. IIS заботиться о здоровье вашего приложения, упавшие экземпляры будут подниматься автоматически. Те, которые забывают освобождать память будут переодически рестартованы и т.д. и т.п.

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

S>>> У среднего слоя основная задача — разделять дефицитные ресурсы (соединения с БД, сетевые соединения, память) между клиентами.
H>>А если в среднем слое разместить бизнес-логику? ИМХО он для этого очень хорошо подходит. А вот использовать его в основном для разделения дефицитных ресурсов типа соединения с БД я лично не вижу большого смысла. С таким же успехом можно просто использовать пул подключений на сервере БД и открывать коннекшин к базе на клиенте только когда он реально нужен.
S>Это кстати распространенное заблуждение, о том что средний слой был придуман только для размещения бизнес логики
Я не сказал только. Я вот, как раз, спорю с тем, что основная задча среднего слоя та, которую указал ты Соединение с базой — его можно разделять и не только с среднего слоя, сетевое соединение — не совсем понятно, что имеется в виду, с кем соединение? Память — ее и на клиентских компах щас вполне хватает.
S>>> А для этого средний слой должен очень эффективно работать с ресурсами в многопоточной среде. Выбор windows service означает, что всей этой работой вы намерены заниматься самостоятельно. Справитесь? Может лучше IIS?
H>>А, например, какой-такой работой? Если там ремоутинг, то все запросы приходят в отдельных потоках, основная задача при этом сводится к синхронизации доступа к общим ресурсам. Как IIS в этом поможет?
S>В чем поможет IIS?
S> — встроенная аутентификация клиентов и защищенный канал. Ни того ни другого нет в голом ремотинге.
Это проблема не ремоутинга, а его конкретной реализации от МС. Хотя я бы ремоутинг вообще не использовал
S> — поддержка масштабирования, IIS способен запускать при необходимости несколько пулов для вашего приложения и распределять между запросы между ними
Согласен. Хотя, иногда, лучше масштабировать по кол-ву серверов. Есть, конечно, вэб-фермы...

С последующими пунктами я тоже, в принципе, согласен, но ИМХО лечить это надо, а не надеяться на то, что глючной сервер приложений просто перебутит IIS.
S> — лучшая изоляция процессов. Если ваш сервер крив до не возможности, под IIS у него меньше шансов завалить всю систему.
S> — встроенный recycling. IIS заботиться о здоровье вашего приложения, упавшие экземпляры будут подниматься автоматически. Те, которые забывают освобождать память будут переодически рестартованы и т.д. и т.п.

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

S> — встроенная аутентификация клиентов и защищенный канал. Ни того ни другого нет в голом ремотинге.

Есть.

S> — лучшая изоляция процессов. Если ваш сервер крив до не возможности, под IIS у него меньше шансов завалить всю систему.

Худшая изоляция. Приложения внутри одного пула выполняются в одном процессе со всеми вытекающими.