Глупаво ли е?
10 отговора
634 прегледа
Ами ...
реално не задаваш правилно въпроса ;-)))
Ако не ти се дават пари за third party компоненти - тогава нямаш алтернатива!
Ако оба4е ти трябва нещо по мощно ;-))) - тогава провери тук. Съдържат се BDE алтернативите - добро е и се отнася не само за Oracle
P.S. Ще е хубаво да се запази тази връзка - давана е поне няколко пъти във форума - но явно се забравя. Май ще е хубаво да взема да направя една тема за връзки в началото на форума - както мислех преди месец.
---
Е т'ва е живот!
Ако не ти се дават пари за third party компоненти - тогава нямаш алтернатива!
Ако оба4е ти трябва нещо по мощно ;-))) - тогава провери тук. Съдържат се BDE алтернативите - добро е и се отнася не само за Oracle
P.S. Ще е хубаво да се запази тази връзка - давана е поне няколко пъти във форума - но явно се забравя. Май ще е хубаво да взема да направя една тема за връзки в началото на форума - както мислех преди месец.
---
Е т'ва е живот!
Re: Глупаво ли е?
Зависи какво ти трябва. Аз много мразя BDE-aware контролите, разните там DBEdit, DBComob и прочие. Предпочитам всичко сам да си правя. Затова винаги ползвам някаква форма на direct access.
Написал съм си такива не само за Oracle, но и за MSSQL, MySQL, Interbase. Това изисква малко повече усилие, т.е. да си валидираш сам формите, да менажираш транзакциите и прочие.
Но така приложението ти става доста по-леко, мнооого по-бързо, имаш пълен контрол на достъпа до SQL сървъра. И ползвайки само insert, select, delete и update, приложението става несависимо (е почти:) от конкретна SQL реализиация.
---
Не е важно да си добър, важното е да си ман-и-як!
Написал съм си такива не само за Oracle, но и за MSSQL, MySQL, Interbase. Това изисква малко повече усилие, т.е. да си валидираш сам формите, да менажираш транзакциите и прочие.
Но така приложението ти става доста по-леко, мнооого по-бързо, имаш пълен контрол на достъпа до SQL сървъра. И ползвайки само insert, select, delete и update, приложението става несависимо (е почти:) от конкретна SQL реализиация.
---
Не е важно да си добър, важното е да си ман-и-як!
Re: Глупаво ли е?
Да, аз също мразя гореспоменатите контроли, обаче приложението върху което работя е изграждано вече близо две години върху тях :) Някак не може просто всичко да се пренапише. Иначе този стил ми харесва, но аз нямах предвид точно интерфейсната част свързана с БДЕ. Всъщност предпочитан от мен стил е тя просто да движи написани от мен класове, които всъщност се разполагат с данните. Така приложението става много по-лесно за поддръжка.
-------------
Искам да знам какво мисли Бог - останалото са подробности. (Einstein)
-------------
Искам да знам какво мисли Бог - останалото са подробности. (Einstein)
Редактирано от z_free на
Малка забележка...
Контролите на DB компонентите (стандартните) нямат нищо общо с BDE !!! Ако си погледнал архитектурата - ще си разбрал, 4е между контролата и самата таблица - стои (малко безмислено на пръв поглед) DataSource - това ти гарантира съвместимост между реализациите на TQuery и TTable (последното е доста безмислено за SQL сървър) за разли4ните бази данни. Това, че има проблеми с отделни контроли (май старите look-up не работеха както трябва ) е друг проблем. Още един недостатък е ограничеността в транзакциите - но това се преодолява - връзката на визулните компоненти с базата данни - като управление на транзакциите е най-лошата възможна такава - пример по долу.
Начина по който работиш има един съществен недостатък - не разделяш бизнес логиката от базата данни и визуализацията - тези неща образно казано можеш да си ги представиш като върхове в един триъгълник. Проблема идва при разширяването на логиката на програмата - преработванията са много големи. Реално така могат да се работят малки проекти (е не знам какво то4но правиш).
Мога да ти дам и един не много приятен пример за ДБ визуални компоненти - които работят бързо и прекрасно - в комбинация с компонентите - тези на IBO - за Interbase - вярно, че скоростта е прекрасна - но за сметка на това си ограни4ен в използването на то4но и само тези компоененти. Реално това си е затруднение ако в последствие мигрираш към друга база данни.
Материята е доста хлъзгава - наистина максимална скорост и сигурност постигаш по на4ина по който работиш - но това ти вързва ръцете във функционално отношение - губиш от мащабируемоста и от по сложната (на моменти повтаряща се) функционалност на проекта.
---
Е т'ва е живот!
Начина по който работиш има един съществен недостатък - не разделяш бизнес логиката от базата данни и визуализацията - тези неща образно казано можеш да си ги представиш като върхове в един триъгълник. Проблема идва при разширяването на логиката на програмата - преработванията са много големи. Реално така могат да се работят малки проекти (е не знам какво то4но правиш).
Мога да ти дам и един не много приятен пример за ДБ визуални компоненти - които работят бързо и прекрасно - в комбинация с компонентите - тези на IBO - за Interbase - вярно, че скоростта е прекрасна - но за сметка на това си ограни4ен в използването на то4но и само тези компоененти. Реално това си е затруднение ако в последствие мигрираш към друга база данни.
Материята е доста хлъзгава - наистина максимална скорост и сигурност постигаш по на4ина по който работиш - но това ти вързва ръцете във функционално отношение - губиш от мащабируемоста и от по сложната (на моменти повтаряща се) функционалност на проекта.
---
Е т'ва е живот!
Re: Малка забележка...
Знам, че нямат нищо общо (поне от някоя версия на Delphi нататък, не си спомням това).
А недостатъка за който говориш (бизнес логиката), отдавна съм го преодолял. В смисъл имаме си framework с който се дефинира логиката - връзки между отделните полета, дизайнер за форми и т.н. В някои от проектите, реализирани с това, не сме пре-компилирали .EXE-то и аз непомня откога.
А, че материята е хлъзгава, така е. Общо взето това което сме си направили, върши работа в някои определени случаи. За други просто не става.
Универсално решение, което да е просто и бързо май наистина няма. Или е бързо, но не е мащабируемо или преносимо, или е някакво дето "цепи, лепи и фулканизира", но идва с няколко хиляди страници документация и се разучава с години...
А клиентите, за съжаление не са склонни да плащат за тези години.
---
Не е важно да си добър, важното е да си ман-и-як!
А недостатъка за който говориш (бизнес логиката), отдавна съм го преодолял. В смисъл имаме си framework с който се дефинира логиката - връзки между отделните полета, дизайнер за форми и т.н. В някои от проектите, реализирани с това, не сме пре-компилирали .EXE-то и аз непомня откога.
А, че материята е хлъзгава, така е. Общо взето това което сме си направили, върши работа в някои определени случаи. За други просто не става.
Универсално решение, което да е просто и бързо май наистина няма. Или е бързо, но не е мащабируемо или преносимо, или е някакво дето "цепи, лепи и фулканизира", но идва с няколко хиляди страници документация и се разучава с години...
А клиентите, за съжаление не са склонни да плащат за тези години.
---
Не е важно да си добър, важното е да си ман-и-як!
New - За биснес логиката
Начина по който работиш има един съществен недостатък - не разделяш бизнес логиката от базата данни и визуализацията - PhantomAS
Това не ми е съвсем ясно. Ако пиша информационна система за застрахователна компания например, съдържаща полиците и застрахованите, тогава мога да реша да направя клас ТПолица. Той ще има полета ПритежателНаПолица (което също ще е клас), ЗастрахованОбект (класс агейн), етц., Метод ЗапишиВбазата, който ще създава динамично копмпоненти за достъп и ще пишe по най-различни таблици. Така интерфейса просто ще инициализира полетата на класовете и може да бъде модифициран без никакви сътресения. Но какво ще рече "неразделяне на бизнес логиката от базата"?
ПС: от този ъгъл погледното - ще се телят волове докато се напишат класовете
А транзакциите.. ау.
-------------
Искам да знам какво мисли Бог - останалото са подробности. (Einstein)
Това не ми е съвсем ясно. Ако пиша информационна система за застрахователна компания например, съдържаща полиците и застрахованите, тогава мога да реша да направя клас ТПолица. Той ще има полета ПритежателНаПолица (което също ще е клас), ЗастрахованОбект (класс агейн), етц., Метод ЗапишиВбазата, който ще създава динамично копмпоненти за достъп и ще пишe по най-различни таблици. Така интерфейса просто ще инициализира полетата на класовете и може да бъде модифициран без никакви сътресения. Но какво ще рече "неразделяне на бизнес логиката от базата"?
ПС: от този ъгъл погледното - ще се телят волове докато се напишат класовете
А транзакциите.. ау.
-------------
Искам да знам какво мисли Бог - останалото са подробности. (Einstein)
Редактирано от z_free на