Здравствуйте, alexdr, Вы писали:
A>Имеется довольно типичная архитектура N-layer со следующими слоями:
A>1) Data access layer;
A>2) Business rules layer;
A>3) Business Facade layer;
A>4) Webservice layer;
A>5) Web User Interface layer.
A>Назначение слоев понятно из названий. Планируется, что веб-сервисы будут переносить туда-сюда типизированные датасеты. Вопрос в том, в каком слое должны быть имплементированы эти самые датасеты?
Интересные вы вопросы задаете, батенька. Я думаю, нет сомнений в том, что все слои, которые с ними работают, должны иметь эту "имплементацию" (я правильно понимаю, что имеется в виду код?) при развертывании. То есть, по сути, это некая часть интерфейса между всеми слоями. Ну вот и ответ — ни в каком
Они общие.
Ну представь, если бы они "имплементировались" в слое Business rules. Тогда, по идее, в Data access можно сунуть простой DataSet (то есть как нетипизированный). Но вот с вышележащими слоями есть проблема: они так и не узнают об этих самых датасетах выше фасада. Так вот и получается, что в фасад тогда должны приходить какие-то общие типы, скорее всего тогда простые, которые этот фасад перегоняет в типизированные датасеты и сует бизнесу. Бред какой-то, ей богу...
Поэтому типизированные датасеты — это своего рода пассивыные насители структурированных бизнес-данных, то есть эдакие бизнес-ентити без логики, data transfer objects (см.
http://www.martinfowler.com/eaaCatalog/dataTransferObject.html). И о них должны знать все заинтересованные в их использовании стороны.
Резюме: реализация типизированных датасетов не должна принадлежать никакому слою, она сама по себе и все заинтересованные слои ею пользуются.
По-моему, так.
Здравствуйте, Козьма Прутков, Вы писали:
КП>Интересные вы вопросы задаете, батенька. Я думаю, нет сомнений в том, что все слои, которые с ними работают, должны иметь эту "имплементацию" (я правильно понимаю, что имеется в виду код?) при развертывании. То есть, по сути, это некая часть интерфейса между всеми слоями. Ну вот и ответ — ни в каком Они общие.
Я неправильно выразился. Каждый слой реализуется в виде отдельной сборки. Вопрос был о том, в какой именно сборке должны быть реализованы типизированные датасеты.
КП>Ну представь, если бы они "имплементировались" в слое Business rules. Тогда, по идее, в Data access можно сунуть простой DataSet (то есть как нетипизированный). Но вот с вышележащими слоями есть проблема: они так и не узнают об этих самых датасетах выше фасада. Так вот и получается, что в фасад тогда должны приходить какие-то общие типы, скорее всего тогда простые, которые этот фасад перегоняет в типизированные датасеты и сует бизнесу. Бред какой-то, ей богу...
Правильно ли я понимаю логику работы приложения с подобной архитектурой? Контролы веб-формы связаны с типизированным датасетом. Пользователь вводит данные в веб-форму, которые затем с помощью этого самого датасета передаются веб-сервисом в фасад. Фасадный класс вызывает, в том числе, метод класса из слоя бизнес-правил, который, в свою очередь, обращается к методу объекта из слоя Data access? Или фасадный класс может напрямую вызывать метода из слоя Data access? Что-то я здесь запутался
КП>Поэтому типизированные датасеты — это своего рода пассивыные насители структурированных бизнес-данных, то есть эдакие бизнес-ентити без логики, data transfer objects (см. http://www.martinfowler.com/eaaCatalog/dataTransferObject.html).
Здесь все понятно.
КП>И о них должны знать все заинтересованные в их использовании стороны.
КП>Резюме: реализация типизированных датасетов не должна принадлежать никакому слою, она сама по себе и все заинтересованные слои ею пользуются.
Классы каких именно слоев могут быть заинтересованы в использовании типизированных датасетов?
Здравствуйте, alexdr, Вы писали:
A>Я неправильно выразился. Каждый слой реализуется в виде отдельной сборки. Вопрос был о том, в какой именно сборке должны быть реализованы типизированные датасеты.
Соответственно, в своей или по меньшей мере в какой-то общей. Кстати, не стоит искать соотношения между слоями (логическими единицами) и сборками (единицами развертывания). Один слой может состоять из массы сборок, плюс еще пользоваться другими (библиотеками какими нибудь, общими интерфейсными и утилитарными сборками и т.п.) Несколько слоев тоже могут быть реализованы в одной сборке (то есть, например, фасад, бизнес и слой доступа к данным). По сути, сборка с датасертами — утилитарный пакет (по RUP.NET):
Typed DataSet: A Design Class stereotyped as «DataSet». Organize into packages named "Utility Classes"
A>Правильно ли я понимаю логику работы приложения с подобной архитектурой? Контролы веб-формы связаны с типизированным датасетом. Пользователь вводит данные в веб-форму, которые затем с помощью этого самого датасета передаются веб-сервисом в фасад. Фасадный класс вызывает, в том числе, метод класса из слоя бизнес-правил, который, в свою очередь, обращается к методу объекта из слоя Data access? Или фасадный класс может напрямую вызывать метода из слоя Data access? Что-то я здесь запутался
Да, есть в слоировании некоторая путаница. Но все разруливается 2-мя вариантами:
strict layering — ситуация, в которой каждый слой может взаимодействовать только со своими непосредственными соседями (то есть вызываться только из того слоя, который лежит непосредственно над ним, и вызывать только тот слой, который непосредственно под ним). При этом достигается хорошая modifiability, но нужно писать кучу кода, который по сути только делегирует вызовы нижележащим слоям (зато потом в этот код можно довесить логику, и никто об этом не узнает).
relaxed layering — обратная ситуация. Слой может пользоваться всем, что ниже него. Тут как раз писать надо меньше, но и modifiability будет похуже.
A>Классы каких именно слоев могут быть заинтересованы в использовании типизированных датасетов?
Ну, по логике вещей, UI (который транслирует эти данные в доступную пользователю форму и обратно, к тому же удобство дизайнера не стоит отрицать), бизнесу, который этими данными как-то манипулирует, и видимо слою доступа к данным, который транслирует эти данные в структуру, понятную БД, условно говоря. Соответственно, все кто эти данные передает (фасад, сервис-фасад) тоже должны о них знать (а то как же с сигнатурами функций). В .NET слой данных, конечно, может и обойтись: если все взаимодействие с БД на ХП через дата-адаптеры, то ему по бльшому счету пофигу до типизированности этих датасетов, все равно адаптеры оперируют текстовыми именами таблиц и полей, которые в них вероятнее всего занесли при конфигурировании. Но все остальные вроде как не пострадают от их наличия.
