Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации.
1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД.
2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете?
Здравствуйте, Tom, Вы писали:
Tom>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации. Tom>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД. Tom>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
3. Middle Tier — COM+ приложение, которое предоставляет свой интерфейс. Заодно можно будет использовать в бизнес логике сервисы COM+. Зачастую безболезнено можно переводить этот слой как в библиотеку, так и в сервер
Tom>Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете?
Здравствуйте, Ведмедь, Вы писали:
Tom>>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
В>3. Middle Tier — COM+ приложение, которое предоставляет свой интерфейс. Заодно можно будет использовать в бизнес логике сервисы COM+. Зачастую безболезнено можно переводить этот слой как в библиотеку, так и в сервер
По моему, пункт 2 это подрузомевал. А если уж выбирать между Remoting и COM+, то я бы выбрал Web Services Хотя тут все зависит от специфичности задачи...
Здравствуйте, Tom, Вы писали:
Tom>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации. Tom>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД.
Tom>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
Вообщето доступ к базе это подвид бизнес логики,
т.е. доступ к базе осуществляется через интерфейсы, и самой бизнес логике должно быть фиолетово как ты делаешь отдельной DLL или сервисом, т.к. реализоваться должно через отдельный компонент.
тут уже из личного предпочтения надо выбирать и требованиям к системе
Я бы сделал в бизнес логике отдельный компоненд доступа к базам, который содержит список интфейсов компонентов и делегирует доступ к базе.
У меня сделано вообще так
/--- бизнес компонент 1 ---\ /-- DLL для ADO/XML------------\
ГУИ --- ФАСАДНЫЙ КЛАСС---|---- бизнес компонент 2 ----|--- КОМПОНЕТ ДОСТУПА К БАЗЕ --- --- DB
\--- бизнес компонент 3 ---/ \-- Сервис для Native DBF/OCI--/
Здравствуйте, Tom, Вы писали:
Tom>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации. Tom>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД. Tom>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
Tom>Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете?
Моё imho голосует за второй подход. Конечно всё можно подвергать сомнению и много зависит от типа проекта, но...
1) Если необходимо внести изменения в реализацию уровня бизнес-логики, то проще потом переинсталлять один сервер, чем k клиентов
2) Если предполагается одновременная работа (возможно различных) клиентов с одними и теми же объектами бизнес-логики, то лучше их разместить на сервере или придется продумать, как им сообщать об изменениях локальных копий (и вообще, сразу появится вопрос с целостностью распределенных данных)
3) По опыту: 2 типа построение системы психологически располагает к аккуратному проектированию. Вероятно потому, что хорошо прослеживается граница между уровнем бизнес-логики и уровнем пользовательских приложений.
Здравствуйте, Tom, Вы писали:
Tom>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации. Tom>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД. Tom>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
Tom>Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете?
Имхо, если приложение небольшое, то лучше первый вариант — простота и все такое. Если же надо полномасштабное приложение на большое количество пользователей, то тогда 2 — безопасность, надежность, возможность распределения нагрузки и.т.п. Какие основные требования к этим приложениям? Хоть немного обрисуй — тогда можно будет конкретнее что-то сказать...
В>3. Middle Tier — COM+ приложение, которое предоставляет свой интерфейс. Заодно можно будет использовать в бизнес логике сервисы COM+. Зачастую безболезнено можно переводить этот слой как в библиотеку, так и в сервер
COM+ может быть задеплоен как оба моих варианта и его преймущества я не хотел бы обсуждать. Вопрос не в них, а в архитектуре.
Tom>>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации. Tom>>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД. Tom>>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
Tom>>Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете? Ved>Имхо, если приложение небольшое, то лучше первый вариант — простота и все такое. Если же надо полномасштабное приложение на большое количество пользователей, то тогда 2 — безопасность, надежность, возможность распределения нагрузки и.т.п. Какие основные требования к этим приложениям? Хоть немного обрисуй — тогда можно будет конкретнее что-то сказать...
В общем требования тяжело обрисовать. Есть нейкий портал с кол-во обращений скажем к IIS 1.000.000 в сутки. Пользователей много там итд. Я вот не особо понял как 1-вый вариант соотносится с секурити? Мы же можем каждый вызов бизнесс обьекта авторизовывать... Распределение нагрузки — это гуд, но тут тоже думать надо.
Здравствуйте, Ved, Вы писали:
Tom>>Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете? Ved>Имхо, если приложение небольшое, то лучше первый вариант — простота и все такое. Если же надо полномасштабное приложение на большое количество пользователей, то тогда 2 — безопасность, надежность, возможность распределения нагрузки и.т.п. Какие основные требования к этим приложениям? Хоть немного обрисуй — тогда можно будет конкретнее что-то сказать...
Надо сравнивать не по простоте приложения, а по предназначению. Если программа популяционнго типа — первый пункт сам собою отпадает. Я лично даже не представляю, как можно клиенту дать код, работающий с SP.
Здравствуйте, Tom, Вы писали:
Tom>>>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации. Tom>>>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД. Tom>>>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
Tom>>>Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете? Ved>>Имхо, если приложение небольшое, то лучше первый вариант — простота и все такое. Если же надо полномасштабное приложение на большое количество пользователей, то тогда 2 — безопасность, надежность, возможность распределения нагрузки и.т.п. Какие основные требования к этим приложениям? Хоть немного обрисуй — тогда можно будет конкретнее что-то сказать...
Tom>В общем требования тяжело обрисовать. Есть нейкий портал с кол-во обращений скажем к IIS 1.000.000 в сутки. Пользователей много там итд. Я вот не особо понял как 1-вый вариант соотносится с секурити? Мы же можем каждый вызов бизнесс обьекта авторизовывать... Распределение нагрузки — это гуд, но тут тоже думать надо.
То есть клиент у вас один — IIS один или их стоит несколько? Есть ли другие клиенты( не IIS)?
Здравствуйте, Tom, Вы писали:
Tom>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации. Tom>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД. Tom>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
Tom>Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете?
При определённой сноровке можно сделать так, что между 1 и 2 не будет никакой разницы и первое будет становиться вторым несложными изменениями в конфигурационных файлах.
В общем, не на том акцентируете внимание, товарищи.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>При определённой сноровке можно сделать так, что между 1 и 2 не будет никакой разницы и первое будет становиться вторым несложными изменениями в конфигурационных файлах.
+
IT>В общем, не на том акцентируете внимание, товарищи.
Почему же? MidleTier — это своего рода "правило" построения программ. Но в топики начали обсуждать клиент-серверное взаимодействие. Так как одним правилом сыт не будешь, то это верный путь .
В>То есть клиент у вас один — IIS один или их стоит несколько? Есть ли другие клиенты( не IIS)?
Да есть. просто я IIS привёл для того что бы показать обьём нагрузки.
Здравствуйте, Mika Soukhov, Вы писали:
MS>Почему же? MidleTier — это своего рода "правило" построения программ.
Такое определение middle tier пожалуй имеет право на существование
MS>Но в топики начали обсуждать клиент-серверное взаимодействие. Так как одним правилом сыт не будешь, то это верный путь .
Прежде всего нужно не путать тёплое с мягким и разделять такие вещи как слоёные приложения вообще и клиентсерверные с использованием сервера приложений. Судя по сабжику совершенно непонятно о чём идёт речь. Например, middle tier вовсе не обязательно должен работать на отдельном сервере. Это всего лишь логическая прослойка между клиентом и источником данных.
Для обозначения того о чём говорит Tom лучше подходит другой более узкий термин — middleware, но и с ним происходит постоянная путаница. Например, встречаются переводы типа "ПО средней сложности".
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Tom, Вы писали:
Tom>>>Допустим надо организовать ряд приложений для работы с БД. Выбрана модель 3-tier. Есть 2 способо организации. Tom>>>1. Middle Tier — это отдельная dll которая используется всеми приложениями, которые хотя получить доступ к БД и использовать бизнесс логику, зашитую в данной БД. Tom>>>2. Middle Tier — приложение (NT сервис), которое предоставляет нейкие сервисы через сетевой интерфейс (.NET Remoting). Приложения которые хотят работать с БД используют эти интерфейсы.
Tom>>>Хотелось бы обсудить все плюсы/минусы обоих подходов. Что скажете? Ved>>Имхо, если приложение небольшое, то лучше первый вариант — простота и все такое. Если же надо полномасштабное приложение на большое количество пользователей, то тогда 2 — безопасность, надежность, возможность распределения нагрузки и.т.п. Какие основные требования к этим приложениям? Хоть немного обрисуй — тогда можно будет конкретнее что-то сказать...
Tom>В общем требования тяжело обрисовать. Есть нейкий портал с кол-во обращений скажем к IIS 1.000.000 в сутки. Tom>Пользователей много там итд. Я вот не особо понял как 1-вый вариант соотносится с секурити? Tom>Мы же можем каждый вызов бизнесс обьекта авторизовывать...
А почему "МЫ"? на уровне COM+ установим права для компонентов и все.
Распределение нагрузки — это гуд, но тут тоже думать надо.
а тут уже советую посмотреть в сторогу GRID и SOA — на сайте оракле посмотри, у них уже есть готовая
технология по распределению нагрузки между серверами, может идей какихто почерпнешь оттуда
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Mika Soukhov, Вы писали:
MS>>Почему же? MidleTier — это своего рода "правило" построения программ.
IT>Такое определение middle tier пожалуй имеет право на существование
MS>>Но в топики начали обсуждать клиент-серверное взаимодействие. Так как одним правилом сыт не будешь, то это верный путь .
IT>Прежде всего нужно не путать тёплое с мягким и разделять такие вещи как слоёные приложения вообще и клиентсерверные с использованием сервера приложений. Судя по сабжику совершенно непонятно о чём идёт речь. Например, middle tier вовсе не обязательно должен работать на отдельном сервере. Это всего лишь логическая прослойка между клиентом и источником данных.
IT>Для обозначения того о чём говорит Tom лучше подходит другой более узкий термин — middleware, но и с ним происходит постоянная путаница. Например, встречаются переводы типа "ПО средней сложности".
Да ладно термины. Фиг с ними. Я ж о реалиях. Прикинь как красиво будет если всё:
В COM+ App, Role Based забомбить на основе NT пользователей, Купить сервак и Load Balancing сделать. Тут тебе и секурити, и 3-тиер и всё как учат в школе.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Mika Soukhov, Вы писали:
MS>>Почему же? MiddleTier — это своего рода "правило" построения программ.
IT>Такое определение middle tier пожалуй имеет право на существование
Ну конечно же. N-tier.
MS>>Но в топики начали обсуждать клиент-серверное взаимодействие. Так как одним правилом сыт не будешь, то это верный путь .
IT>Прежде всего нужно не путать тёплое с мягким и разделять такие вещи как слоёные приложения вообще и клиентсерверные с использованием сервера приложений. Судя по сабжику совершенно непонятно о чём идёт речь. Например, middle tier вовсе не обязательно должен работать на отдельном сервере. Это всего лишь логическая прослойка между клиентом и источником данных.
Дык ты видел смайлик? Начали c проектирования — закончили COM+.
Кстати, сейчас модно обсуждать распределенные системы, и "прибивать" их к Нету. Просто куда не плюнь везде распределенщина. Как же раньше было без него. И ведь все все знали Это все происки MS
IT>Для обозначения того о чём говорит Tom лучше подходит другой более узкий термин — middleware, но и с ним происходит постоянная путаница. Например, встречаются переводы типа "ПО средней сложности".
Middle Ware — это то, из чего состоит средний уровень, в детальной расстановке. Вопрос же был, куда его (Midddle Tier) присобачивать в 3-tier приложения.
Здравствуйте, mikа, Вы писали:
M>Middle Ware — это то, из чего состоит средний уровень, в детальной расстановке. Вопрос же был, куда его (Midddle Tier) присобачивать в 3-tier приложения.
Дык ясен перь куда. В середину. Оно ж middle.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, mikа, Вы писали:
M>>Middle Ware — это то, из чего состоит средний уровень, в детальной расстановке. Вопрос же был, куда его (Midddle Tier) присобачивать в 3-tier приложения.
IT>Дык ясен перь куда. В середину. Оно ж middle.
Спасибо. Щас возьму и прикручу посередине. Где тут у меня отвертка?
Хотя тут все зависит от специфичности задачи...
Если нам не помогут, то мы тоже никого не пощадим.
.
Начали c проектирования — закончили COM+.
Это все происки MS