|
|
|
Концепция создания клиентского приложения SQL
|
|||
|---|---|---|---|
|
#18+
Добрый день! Всем известно что врямя от времени Microsoft радует нас новыми средствами доступа к данным: DAO, ADO и вот теперь ADO.Net. И если преход с DAO на ADO достаточно прост, то при переходе на .Net легче все пиреписать с нуля. В этой связи существует вопрос о таком проектировании клиентской части, при котором бы при изменении интерфейса доступа изменениям подвергались бы лишь некоторые ключевые процедуры доступа к базе. Может кто-нибудь уже реализовывал нечто подобное и может рассказать об принципах построения таких систем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2002, 09:08:32 |
|
||
|
Концепция создания клиентского приложения SQL
|
|||
|---|---|---|---|
|
#18+
Есть некоторые ... хм.. не будем плохими словами..., которые делают систему а потом заявляют: Работает на всем, чем только можно, от Paradox до Oracle!!! Я даже знаю, как они называются (фирма в смысле:) Это наверное то, что вам нужно. Универсальный доступ к данным через промежуточный слой. Но тогда забудьте про использование хранимых процедур, обработки данных на сервере и т.д. Сервер будет использоваться как одна большая dbf. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2002, 12:35:19 |
|
||
|
Концепция создания клиентского приложения SQL
|
|||
|---|---|---|---|
|
#18+
Ну в таком случае тебе нужен объект с методами! ConnectDB ExecSQL MoveFirst (?) MoveLast (?) MoveNext MovePrevious (?) CloseDB Вопросами отмечены методы которые по идеи не должны входить в этот набор, но с ними иногда удобней! Так вот скудный набор этих методов меня натолкнул на мысль об ODBC наверное! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2002, 12:41:26 |
|
||
|
Концепция создания клиентского приложения SQL
|
|||
|---|---|---|---|
|
#18+
Вообще, если ходить через ADO к разным серверам, то проблем нет. А если менять ADO на что-то, то да, нужен свой компонент, внутри которого доступ можно править как хочешь, а снаружи все одинаково ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2002, 13:12:18 |
|
||
|
Концепция создания клиентского приложения SQL
|
|||
|---|---|---|---|
|
#18+
По-моему, любой хоть сколько-то сложный и долгоживущий продукт использует свой компонент для доступа к БД. У меня в последние несколько лет не было программ без такого компонента. А "насыщение" кода работой с ADO (DAO, ODBC...) считаю неправильной - я много раз сталкивался с необходимостью внести изменения в доступ к БД после выхода сервис-пака (иои новой версии). Пока не перешли на использование своих компонентов доступа, приходилось менять сотни фацлов с кодом... А компонент нужен простенький - не надо изобретать что-то совсем новое, просто небольшая оболочка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2002, 13:31:32 |
|
||
|
Концепция создания клиентского приложения SQL
|
|||
|---|---|---|---|
|
#18+
Так у нас тоже свой компонент. Тока он через ADO ходит. Но нет проблем переделать его внутри, если надо Так и делаем :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2002, 13:35:10 |
|
||
|
Концепция создания клиентского приложения SQL
|
|||
|---|---|---|---|
|
#18+
А если нужно использовать Grid, то это просто грид без привязки к данным и последующим апдейтом модифицированных строк? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2002, 14:06:35 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32071954&tid=1818527]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
60ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 348ms |

| 0 / 0 |
