|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
Здравствуйте уважаемые форумчане Наконец-то я столкнулся с достаточной распространённой задачей, в которой у меня огромный пробел. Обращаюсь на форум, потому что здесь полно спецов, в том числе и по БД, и по сетям. От вас мне нужны мысли, ссылки на статьи и зарекомендовавшие себя подходы. Только у меня большая просьба. Видимо тут заведено, что каждый что-либо незнающий должен тратить часы и дни на поиски мелочей, должен погрязать в рутине. Просьба такая. Давайте не будем усложнять друг другу жизнь, будем изъясняться простым языком, описывая больше деталей. Опишите просто в теории, в реализации я сам погрязну, без всякой помощи ) Итак задача у меня - организовать многопользовательскую систему (человек 30) с доступом к общим данным. У каждого пользователя будет клиентское приложение, которое будет обращаться к серверу (сервер мне выделят). Пользователи будут оперировать общими данными (БД) и файлами. У нас лицензия и спецы на MS SQL Server (будет либо 2005, либо 2008). У каждого пользователя есть права (среди которых административные). Пишу на Delphi. Соответственно появляется много вопросов: 1) можно ли отделаться только базой данных. Мне сказали, что не правильно хранить файлы в БД 2) какие компоненты и библиотеки нужно использовать для работы с MS SQL Server 3) каким образом принято разграничивать права пользователей Соответственно появляется мысль, что нужно организовать серверное приложение, которое будет прослойкой между клиентом и базой данных с файлами. Тут ещё больше вопросов: 1) какими компонентами пользоваться для организации клиент-серверной архитектуры 2) каким образом организовать систему входа (логин/пароль) и определять права пользователей 3) как реагировать на разрыв связи и прочие неполадки с коннектом, как отлавливать 4) как организовать передачу файлов 5) как вообще обмениваться данными между сервером и приложением. тут ведь не просто строку надо передавать. тут более сложные механизмы Ну и потом по БД интересна информация. В каких случаях нужно создавать справочники, как увязывать между собой сущности и т.д. + как грамотно реализовать автоматический апдейт клиентского приложения В целом - интересуют зарекомендовавшие себя подходы. Вопросы простые, но их много. Помогайте чем можете - всё пригодится. Только поинформативнее и попроще ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 12:27 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
SOFT FOR YOUСоответственно появляется много вопросов: 1) можно ли отделаться только базой данных. Мне сказали, что не правильно хранить файлы в БД Можно. Вообще, где хранить файлы, в БД или файловой системе - вопрос скорее холиварный. MS SQL вполне себе справляется с большим количеством БЛОБов. SOFT FOR YOU2) какие компоненты и библиотеки нужно использовать для работы с MS SQL Server В Delphi не слишком много вариантов (это хорошо, кстати). DBGo сиречь ADO. SOFT FOR YOU3) каким образом принято разграничивать права пользователей ммм... есть миллион способов, общепринятого нет. Но как минимум следует использовать средства безопасности MS SQL. SOFT FOR YOUСоответственно появляется мысль, что нужно организовать серверное приложение, которое будет прослойкой между клиентом и базой данных с файлами. Тут ещё больше вопросов: Зачем? Чтобы больше попрограммировать? SOFT FOR YOU1) какими компонентами пользоваться для организации клиент-серверной архитектуры Клиент-серверная архитектура - это твое приложение + MS SQL. Если добавляешь еще одно серверное приложение, это уже трехзвенка. SOFT FOR YOU2) каким образом организовать систему входа (логин/пароль) и определять права пользователей Правильнее всего - использовать виндовый домен и средства доменной аутентификации, благо, MS SQL их отлично поддерживает. SOFT FOR YOU3) как реагировать на разрыв связи и прочие неполадки с коннектом, как отлавливать 4) как организовать передачу файлов 5) как вообще обмениваться данными между сервером и приложением. тут ведь не просто строку надо передавать. тут более сложные механизмы Эти и массу других громоздких проблем тебе не придется решать, если ты откажется от среднего звена. Трехзвенка нужна для разных случаев: - балансировка высокой нагрузки - независимость от СУБД - сложные серверные бизнес-процессы У тебя есть хоть какая-то потребность в этом? SOFT FOR YOUНу и потом по БД интересна информация. В каких случаях нужно создавать справочники, как увязывать между собой сущности и т.д. + как грамотно реализовать автоматический апдейт клиентского приложения ...и как вообще писать программы? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 13:07 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
Спасибо, очень интересно я уже 13 лет занимаюсь программированием, но с сетевым взаимодействием и программированием БД сталкивался как-то слиииишком редко ok. тогда может подскажите мне какую-нибудь интересную статью или комплекс уроков, где описывается проектирование БД. из тех соображений, которые приняты в современном мире (в том смысле, что теоретики с опытом 30 летней давности слабо интересуют) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 14:26 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
Банальная 2-х звенка: логика на хранимых процедурах, тонкий клиент для вызова ХП + отображение результатов. Естественно со своими + и -, но в общем случае намного больше минусов. Не проще ли смотреть пересмотреть платформу реализации, например, Java \ .NET ? Для них это банальная задача ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 14:27 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
mvn3Банальная 2-х звенка: логика на хранимых процедурах, тонкий клиент для вызова ХП + отображение результатов. С точки зрения сложности реализации это тоже вариант "чтобы попрограммировать побольше". Имя в руках мощную среду разработки и не имея никаких конкретных требований к архитектуре приложения, нет смысла тратить время на реализацию бизнес-логики на SQL-сервере, отказываясь от намного более мощного инструмента разработки. mvn3Не проще ли смотреть пересмотреть платформу реализации, например, Java \ .NET ? Для них это банальная задача Не проще. Это абсолютно банальная задача для любой приличной платформы последних полутора десятилетий - PHP, Delphi, даже PowerBuilder :) Пусть делает на том, что уже знает. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 15:31 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
SOFT FOR YOUможно ли отделаться только базой данных. Мне сказали, что не правильно хранить файлы в БДЗависит от объёма файлов, если не очень большой, то проще хранить в БД и ограничиться 2-х звенкой. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 15:31 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
SOFT FOR YOUok. тогда может подскажите мне какую-нибудь интересную статью или комплекс уроков, где описывается проектирование БД. из тех соображений, которые приняты в современном мире (в том смысле, что теоретики с опытом 30 летней давности слабо интересуют) Не подскажу. Опыт приходит с практикой, и я не знаю какую-то конкретную классную книгу/статью, которую прочитаешь - и сразу станешь специалистом :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 15:32 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
ДжекНепотрошительmvn3Банальная 2-х звенка: логика на хранимых процедурах, тонкий клиент для вызова ХП + отображение результатов. С точки зрения сложности реализации это тоже вариант "чтобы попрограммировать побольше". Имя в руках мощную среду разработки и не имея никаких конкретных требований к архитектуре приложения, нет смысла тратить время на реализацию бизнес-логики на SQL-сервере, отказываясь от намного более мощного инструмента разработки.Зато 2-х звенку проще программировать, кода меньше писать и проще сопровождать в случае, если логика будет в ХП на сиквеле. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 15:33 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
SOFT FOR YOUok. тогда может подскажите мне какую-нибудь интересную статью или комплекс уроков, где описывается проектирование БД. из тех соображений, которые приняты в современном мире (в том смысле, что теоретики с опытом 30 летней давности слабо интересуют)К сожалению, книг теоретиков 30 летней давности не бывает, все они старее. Книге Дейта "Введение в системы баз данных" уже 38 лет :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 15:38 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
SOFT FOR YOUСоответственно появляется много вопросов: 1) можно ли отделаться только базой данных. Мне сказали, что не правильно хранить файлы в БД Можно. Только если объем файлов будет в рамках разумного. 2) какие компоненты и библиотеки нужно использовать для работы с MS SQL Server Поскольку с делфями я недружу, то смотри сам. Из распространенных ADO, ну а конкретно - зависит от приложения. 3) каким образом принято разграничивать права пользователей Если речь о скуле мелкомягких то лучше на уровне доменной учетки. Соответственно появляется мысль, что нужно организовать серверное приложение, которое будет прослойкой между клиентом и базой данных с файлами. Это стопудово в данном контексте лишнее. Ну и потом по БД интересна информация. В каких случаях нужно создавать справочники, как увязывать между собой сущности и т.д. + как грамотно реализовать автоматический апдейт клиентского приложения Эм... Ну даже и незнаю. Учиться, учиться, ... По клиенту - зависит от разработчика, по БД - от архитектора БД. В целом - интересуют зарекомендовавшие себя подходы. Самое простое - если являешся спецом по приложению, то отдай на сторону разработку БД. Ну и наоборот. Одним словом делай то что умеешь, а то чего незнаешь лучше отдать на сторону. Это сэкономит кучу времени, сил и нервов. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 15:51 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
alexeyvgЗато 2-х звенку проще программировать, кода меньше писать Это само собой. Но толстый клиент проще программировать и отлаживать, нежели тонкий клиент и логику на ХП. alexeyvg и проще сопровождать в случае, если логика будет в ХП на сиквеле. Это, пожалуй, единственное преимущество. С другой стороны, автоматическое обновление толстых клиентов уже давно и много раз решенная задачка. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 15:56 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
ДжекНепотрошительС другой стороны, автоматическое обновление толстых клиентов уже давно и много раз решенная задачка.Может и давно, но я такого не видел. Всегода требуют окна для апдэйта, на лету что то никто не обновляет. Ну и "легко сопровождать" - это не относится к тому, решена ли задача автоматического обновления. Легко сопровождать - это значит, что стоимость изменения функциональности и правки багов небольшая, и что это может быть легко сделано новым человеком. ДжекНепотрошительalexeyvgЗато 2-х звенку проще программировать, кода меньше писать Это само собой. Но толстый клиент проще программировать и отлаживать, нежели тонкий клиент и логику на ХП.Сложнее, почему же проще? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 16:47 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
alexeyvgНу и "легко сопровождать" - это не относится к тому, решена ли задача автоматического обновления. Легко сопровождать - это значит, что стоимость изменения функциональности и правки багов небольшая, и что это может быть легко сделано новым человеком. За счет чего? Чем код на T-SQL проще, нежели код на ЯВУ? Учитывая, что бизнес-логика может быть самая разная. ДжекНепотрошительЭто само собой. Но толстый клиент проще программировать и отлаживать, нежели тонкий клиент и логику на ХП.Сложнее, почему же проще? В общем случае - проще. Можно легко пройти по всей цепочке от ввода данных до их обработки, не перескакивая из клиента в серверную часть. Есть более мощные средства отладки, сама по себе архитектура толстого клиента может быть более продуманна, нежели процедурный код на ХП. Обработка исключений, логирование - все это разумнее реализуется на толстом клиенте. Даже такие мелочи, как навигация по коду, значительно облегчают жизнь. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 16:57 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
ДжекНепотрошительВ общем случае - проще. Можно легко пройти по всей цепочке от ввода данных до их обработки, не перескакивая из клиента в серверную часть.Так зато нет разделения уровней, идти всегда нужно по всей цепочке. Цепочка бизнес-логики в ХП короткая, выполнить просто, проследить просто. Именно этим SOA полезна. А работу толстого клианта не то, что отладить по цепочке, её часто многие программисты не знают - не представляют, какие запросы будет выполнять сервер в ответ на действия пользователя (хотя сами программу разработали) - они типа нарисовали программу, а оно само там работает. И даже если находят ошибку - не могут поправить, поскольку опять же оно само работает, программист это не контролирует. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 17:43 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
2 варианта: 1. банальный клиент-сервер, тогда вся логика будет на хранимках, как написали выше 2. ну или middleware, если вообще каша в голове и ничего не понятно, то читайте вводную: http://citforum.ru/SE/middleware/history/ лучший вариант - тупо взять .net или явку, там все есть уже для этого.. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 18:53 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
ДжекНепотрошительЭто само собой. Но толстый клиент проще программировать и отлаживать, нежели тонкий клиент и логику на ХП. Программировать и отлаживать проще всего тогда, когда всё на своём месте. Просто потому, что в этом случае код максимально простой и чистый. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 21:59 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
kosh the bestлучший вариант - тупо взять .net или явку, ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2012, 22:00 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
kosh the bestлучший вариант - тупо взять .net или явку, там все есть уже для этого..Или можно какой нибуть новый функциональный язык, что бы точно не разобраться :-) Какой нет и ява? У человека опыт на дельфи, писать нужно по любому виндового клиента. Зачем для этого изучать трёхзвенную архитектуру и новые языки? Разве что для образования... Вполне нормально на дельфи, с хранением файлов в базе или на файл-сервере, неважно. Кстати, в сиквеле появилась новая фича - FILESTREAM, можно использовать её - это хранение файлов в файловой системе, но работать с ними как с полми в таблицах базы, совершенно прозрачно (указывается при создании таблицы), с всеми секюрити и без доступа к шарам. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 00:00 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
а в чём отличие BLOB от FILESTREAM ? и есть ли FILESTREAM в MS SQL 2005. похоже мне на сервер его установят ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 09:45 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
SOFT FOR YOUи есть ли FILESTREAM в MS SQL 2005. похоже мне на сервер его установятНету, нужен 2008 SOFT FOR YOUа в чём отличие BLOB от FILESTREAM ?В том, что в записи в таблице содержимое BLOB-поля будет хранится не в базе данных, а в отдельном файле, в остальном никакой разницы. При этом к такому полю можно будет обращаться не только через интерфейс к СУБД, но и напрямую, к файловой системе, т.е. файлы не заблокированы. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 10:46 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
softwarerkosh the bestлучший вариант - тупо взять .net или явку, ладно, окей что в дельфи на 2012 год есть для создания middleware? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 12:43 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
> Какой нет и ява? У человека опыт на дельфи, писать нужно по любому виндового клиента. Зачем для этого изучать трёхзвенную архитектуру и новые языки? Разве что для образования... Ага. И после пары лет "разработки" получается глюкавое и наивное подобие java application server. Спасибо - такого говна, понаписанного на дельфи и билдере я насопровождался вволю. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 12:50 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
я правильно понял, что обсуждается архитектура файлопоймки? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 13:19 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
kosh the bestчто в дельфи на 2012 год есть для создания middleware? Уже более 10 лет есть неплохой движок SOAP, позволяющий создавать как крохотные автономные серверы, так и веб-приложения для IIS и Apache. Другого и не нужно, .NET в этом плане, к примеру, ничего принципиально нового и не предлагает. А здесь речь идет о том, что автору middleware вообще нафиг не сдалось. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 13:23 |
|
Мозговой штурм на тему разработки клиент-серверного приложения
|
|||
---|---|---|---|
#18+
kosh the bestАга. И после пары лет "разработки" получается глюкавое и наивное подобие java application server. Спасибо - такого говна, понаписанного на дельфи и билдере я насопровождался вволю. Тебе никогда не приходило в голову, что дерьмовый софт возникает совсем не из-за того, что инструмент разработки плохой? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2012, 13:25 |
|
|
start [/forum/topic.php?fid=33&msg=38094924&tid=1547748]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
69ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 166ms |
0 / 0 |