Достъпдостъпдостъп.....
9 отговора
211 прегледа
Достъпдостъпдостъп.....
Тук се започва нов проект, като целта на задачката е приложението да може да мигрира бързо и лесно към различни бази. Какъв достъп ще препоръчате при това положение? За ODBC някак не ми се мисли много, BDE е прекалено изтъркано.... dbExpress ми се върти в главата, има си доста shortcommings, но и addvantages. Хм?
-------------
Special killer double trouble triple extra nicotine monster!
-------------
Special killer double trouble triple extra nicotine monster!
Да де, ама
Ако го започнеш с ADO обаче го обричаш на УниПлатформеност. Пък на мен ми се иска да има отворена вратичка към Кайликс. Обаче с dbExpress мноого проблемно се оказва да си направя връзка към SQL Server-a. При connect ми казва Error mapping failed. Много странно - юзъра ми е sa, а с ентърпрайз мениджър си достъпвам таблиците без проблем. Дали нямам грешен параметър?
-------------
Special killer double trouble triple extra nicotine monster!
-------------
Special killer double trouble triple extra nicotine monster!
Re: Да де, ама
Проблема ти е другаде - и за да ти го обесня ще ми трябва повече от час да пиша - нямам толкова време- и давам накратце
Ето ти нивата на които можеш да разбиеш едно приложение (общо казано)
1. База данни
2. Преносна среда
3. Драйвер / пакет компоненти за връзка с базата данни - поддържащи съответната преносна среда
4. Бизнес логика
5. Интерфейс за връзка с потребителя
Освен вси4ко това по начина на организация - клиент/сървър - като клиента е fat client или да имаш application server. Разбира се горната схема във втория случай се променя! Бизнес логиката се измества на сървъра и реално клиента няма никакъв пряк достъп до базата данни - което е най-чистата реализация ако търсиш взаимозаменяемост на базата данни.
За твоя начин е подходящ втория подход - да имаш структура thin client - application server - не за друг ами точно за да можеш да отделиш различните вариации на базите данни и тяхната реализация в приложението.
Обаче по-голямата част от компонентите които идват с Delphi не са пригодени за изграждане на thin client приложения - което води до следващия по сериозен въпрос - какви пакети от компоненти има за създаване на application server /thin client? Има - но не и безплатни - при това доста добри неща.
Друг вариант над който доста умувам е да използваш още едно междинно ниво в приложението си - което е АБСОЛЮТНО задължително ако държиш да имаш истинска съвмеситмост на различните бази данни - това е така наречения PERSISTENT FRAMEWORK. Това е набор от функции които ти осигуряват независимостта на горните нива - бизнес логиката и визуализацията. Разбира се изграждането на подобен framewrk - е сложно - но има няколко разработени - единия е Bold другия е REM Objects до колкото си спомням. Лошото е че май никой от тях не върви под Kylix - от където идеята ти за платформена преносимост отива на кино.
Между другото съм много против използването на ADO за подобни цели - това ти вързва ръцете с технология която във всеки момент може да бъде сменена от MS - а ако държиш да не си преработваш нацяло програмта през 5 години - ще трябва да помислиш за нещо друго - макар че все още не съм се сетил каква е алтернативата. Нещо взе да ми омръзва през 3-4 години да сменям изцяло концепцията си за работа.
За потвърждение ето малко от еволюционните глупости на MS
DAO - > ADO - май имат доста несъвместимости
OLE - > COM - > DCOM - последното не работи в интернет както трябва или пък ако работи те подвързва много яко с платформата - а за тези които са забравили е време да си опреснят новите лицензни изисквания на М$
Ако разгледаш тези неща ще установиш, че средното време на живот не е по-голямо от 3-4 години - което ако разработваш система примерно за застраховане или банкова система - си е пълна лудост! Те за това хората в USA си стояха до преди годнина две на ДОС 3 даже и по надолу. Сега мои познати работят по приложения вървящи под NT 3.51 - и никой не иска да си сменя системата на 1-2 години -това го правят само домашните потребители и много малка част от бизнес потребителите.
NET. идеята - която идва да замести DCOM след провала му на тема интернет - добре, единствената ми надежда е че един от главните архитекти е човека който издигна Turbo Pascal - а до нивото на Delphi. Ще видим колко и това ще просъществува - но съм скептично настоен.
Извинявай за дългата лекция, но проблема ти е много по сериозен от избора на пакет с компоненти - ако искаш платформена независимост и възможността да включваш различни бази данни - ще трябва доста да се потрудиш.
---
Е т'ва е живот!
Ето ти нивата на които можеш да разбиеш едно приложение (общо казано)
1. База данни
2. Преносна среда
3. Драйвер / пакет компоненти за връзка с базата данни - поддържащи съответната преносна среда
4. Бизнес логика
5. Интерфейс за връзка с потребителя
Освен вси4ко това по начина на организация - клиент/сървър - като клиента е fat client или да имаш application server. Разбира се горната схема във втория случай се променя! Бизнес логиката се измества на сървъра и реално клиента няма никакъв пряк достъп до базата данни - което е най-чистата реализация ако търсиш взаимозаменяемост на базата данни.
За твоя начин е подходящ втория подход - да имаш структура thin client - application server - не за друг ами точно за да можеш да отделиш различните вариации на базите данни и тяхната реализация в приложението.
Обаче по-голямата част от компонентите които идват с Delphi не са пригодени за изграждане на thin client приложения - което води до следващия по сериозен въпрос - какви пакети от компоненти има за създаване на application server /thin client? Има - но не и безплатни - при това доста добри неща.
Друг вариант над който доста умувам е да използваш още едно междинно ниво в приложението си - което е АБСОЛЮТНО задължително ако държиш да имаш истинска съвмеситмост на различните бази данни - това е така наречения PERSISTENT FRAMEWORK. Това е набор от функции които ти осигуряват независимостта на горните нива - бизнес логиката и визуализацията. Разбира се изграждането на подобен framewrk - е сложно - но има няколко разработени - единия е Bold другия е REM Objects до колкото си спомням. Лошото е че май никой от тях не върви под Kylix - от където идеята ти за платформена преносимост отива на кино.
Между другото съм много против използването на ADO за подобни цели - това ти вързва ръцете с технология която във всеки момент може да бъде сменена от MS - а ако държиш да не си преработваш нацяло програмта през 5 години - ще трябва да помислиш за нещо друго - макар че все още не съм се сетил каква е алтернативата. Нещо взе да ми омръзва през 3-4 години да сменям изцяло концепцията си за работа.
За потвърждение ето малко от еволюционните глупости на MS
DAO - > ADO - май имат доста несъвместимости
OLE - > COM - > DCOM - последното не работи в интернет както трябва или пък ако работи те подвързва много яко с платформата - а за тези които са забравили е време да си опреснят новите лицензни изисквания на М$
Ако разгледаш тези неща ще установиш, че средното време на живот не е по-голямо от 3-4 години - което ако разработваш система примерно за застраховане или банкова система - си е пълна лудост! Те за това хората в USA си стояха до преди годнина две на ДОС 3 даже и по надолу. Сега мои познати работят по приложения вървящи под NT 3.51 - и никой не иска да си сменя системата на 1-2 години -това го правят само домашните потребители и много малка част от бизнес потребителите.
NET. идеята - която идва да замести DCOM след провала му на тема интернет - добре, единствената ми надежда е че един от главните архитекти е човека който издигна Turbo Pascal - а до нивото на Delphi. Ще видим колко и това ще просъществува - но съм скептично настоен.
Извинявай за дългата лекция, но проблема ти е много по сериозен от избора на пакет с компоненти - ако искаш платформена независимост и възможността да включваш различни бази данни - ще трябва доста да се потрудиш.
---
Е т'ва е живот!
Re: Да де, ама
Алтернативата е една - и тя е трислойно приложение. Не случайно братята от Borland толкоз се пъчат с Midas. Въпреки че самия Midas освен идеята няма много хубави неща в него.
3-4 години са голям период - просто софтуера е бързо променящо се нещо. "Бизнес със скоростта на мисълта" - беше казал Били. И пачките които прави са доказателство че е прав.
За да не затъвам в подробности - гениалната идея на трислойното приложение е следната:
1) Среда за визуализация - тук избора на HTML засега е безспорен. Тоест на клиента ще му трябва единствено браузър - нещо което си го има във всички ОС и техните подобия - без инсталация и каквото и да е.
2) Сървърна част. Тук има огромен сблъсък между скорост и преносимост. Логично е ако се търси скорост да се пише ISAPI или подобен компонент за съответния OS. Гадния момент е че човек ще се сблъска с непосилни проблеми при преноса от една на друга платформа - спецификите на операционната система, уеб сървъра, права за достъп и прочее може да глътнат повече време отколкото самото приложение. Колкото и да харесвам идеята за междуплатформерно приложение, това за момента става единствено за приложение, но не и за сървър. За междуплатформени приложения са измислени скриптовете. Те пък са туткави, и с изключение на ASP технологията рядко са обвързани дълбоко с уеб сървъра, което не позволява изпълнение на специфични задачи.
3) База данни. Избора не е голям, и ако си представим че един сървър ще обслужва сума ти заявки, бързодействието става критично. Това от своя страна налага ползването на native компоненти за достъп плюс дълбоко познаване и ползване на предимствата на всяка база, което обезсмисля прехвърлянето от една към друга база данни. Един от малкото смислени и добре направени преходи е Access -> MS SQL Server.
Какви са изводите /за мен де/? Решавам да пиша приложение за достъп до база данни, което да се ползва от максимален брой хора. Ако отхвърля подробностите за цени и прочее, ето и идеалния вариант:
Internet Explorer - 90% пазарен дял
IIS / ISAPI / Delphi - отлично бързодействие и минимално време за разработка
Oracle /или може би MS SQL Server/ - единствените бази данни за които мога да кажа че съм възхитен. Всъщност възхищението ми към Oracle е за самата база, докато за MS SQL е повече за интерфейса.
Останалите решения са компромис, и то непълен, към безсмислената идея за междуплатформеност - в крайна сметка сървъра се инсталира веднъж и на подходящо за целта място.
чети и дишай по-леко
3-4 години са голям период - просто софтуера е бързо променящо се нещо. "Бизнес със скоростта на мисълта" - беше казал Били. И пачките които прави са доказателство че е прав.
За да не затъвам в подробности - гениалната идея на трислойното приложение е следната:
1) Среда за визуализация - тук избора на HTML засега е безспорен. Тоест на клиента ще му трябва единствено браузър - нещо което си го има във всички ОС и техните подобия - без инсталация и каквото и да е.
2) Сървърна част. Тук има огромен сблъсък между скорост и преносимост. Логично е ако се търси скорост да се пише ISAPI или подобен компонент за съответния OS. Гадния момент е че човек ще се сблъска с непосилни проблеми при преноса от една на друга платформа - спецификите на операционната система, уеб сървъра, права за достъп и прочее може да глътнат повече време отколкото самото приложение. Колкото и да харесвам идеята за междуплатформерно приложение, това за момента става единствено за приложение, но не и за сървър. За междуплатформени приложения са измислени скриптовете. Те пък са туткави, и с изключение на ASP технологията рядко са обвързани дълбоко с уеб сървъра, което не позволява изпълнение на специфични задачи.
3) База данни. Избора не е голям, и ако си представим че един сървър ще обслужва сума ти заявки, бързодействието става критично. Това от своя страна налага ползването на native компоненти за достъп плюс дълбоко познаване и ползване на предимствата на всяка база, което обезсмисля прехвърлянето от една към друга база данни. Един от малкото смислени и добре направени преходи е Access -> MS SQL Server.
Какви са изводите /за мен де/? Решавам да пиша приложение за достъп до база данни, което да се ползва от максимален брой хора. Ако отхвърля подробностите за цени и прочее, ето и идеалния вариант:
Internet Explorer - 90% пазарен дял
IIS / ISAPI / Delphi - отлично бързодействие и минимално време за разработка
Oracle /или може би MS SQL Server/ - единствените бази данни за които мога да кажа че съм възхитен. Всъщност възхищението ми към Oracle е за самата база, докато за MS SQL е повече за интерфейса.
Останалите решения са компромис, и то непълен, към безсмислената идея за междуплатформеност - в крайна сметка сървъра се инсталира веднъж и на подходящо за целта място.
чети и дишай по-леко
Re: Да де, ама
1. Примера който ти дадох за банково приложение или застрахователно - е показателен - големите "играчи" не си сменят на 2-3 години софтуера! И по тази то4ка не мисля, че можеш да ме обориш.
2. HTML e една от най-добрите алтернативи - за мултиплатформеност и преносимост, не забравяй че има една много неприятна подробност - а това е трудната валидация на данните - особенно на данни които зависят изключително много от контекста - примерно е трудно да се направи читава счетоводна/складова програма която да работи бързо в HTML броузер, да не говорим за CAD/CAM приложение!!!! Виж тук банкова или застрахователна система имат предимство - данните могат да се разграничат на независими (почти) части и да се валидират независимо.
3. IE има 90% пазарен дял за хората които гледат нет страници - не и за тези които реално го ползват като thin client приложение- не забравяй, че той се придружава с MS сървър от другата страна.
4. Относто IS/ISAPI и Делфи - да наистина си прав за малкото време на разработка - но има една подробност - трудната разширяемост на проекта - от което по-късно се губи много време. Ето защо Dephi (на настоящото ниво) не е подходяща платформа за огромни бизнес приложения. VS също - обикновено се ползват други платформи за разработка писани на споменатите.
5. Реално целия въпрос е политически повече отколкото технически - идеята е в цената и броя клиенти които можеш да привлечеш. Идеята да се влагат много пари в интернет и прочие приложения и компании които с 100 000 долара изведнъж се напомпват умря - за това е и кризата в момента. Ако успееш да предложиш на клиента достатъчно гъвкаво и финансово аргументирано решение - печелиш - но хората с много пари си правят добре сметката за какво ги харчат - и не ги дават лесно.
Т.е. много по лесно е да вземеш от 1000 човека по 50 лева за някаква малка програмка тип склад и фактуриране отколкото да накараш някоя сериозна фирма да ти даде тези 50 000 - примерно - последното важи за БГ пазара основно. Ако ти задължиш клиента да се хвърли на M$$$$$$ платформата и след 1 година му направят проверка и го накарат да киха по 5000- 30000$ на година само заради поддръжката на един MS SQL - не си струва - но вси4ко това си зависи от мащабите на дейността.
Всъщност това което казвам е доразвиване на идеята която ти започна - нищо друго.
---
Е т'ва е живот!
2. HTML e една от най-добрите алтернативи - за мултиплатформеност и преносимост, не забравяй че има една много неприятна подробност - а това е трудната валидация на данните - особенно на данни които зависят изключително много от контекста - примерно е трудно да се направи читава счетоводна/складова програма която да работи бързо в HTML броузер, да не говорим за CAD/CAM приложение!!!! Виж тук банкова или застрахователна система имат предимство - данните могат да се разграничат на независими (почти) части и да се валидират независимо.
3. IE има 90% пазарен дял за хората които гледат нет страници - не и за тези които реално го ползват като thin client приложение- не забравяй, че той се придружава с MS сървър от другата страна.
4. Относто IS/ISAPI и Делфи - да наистина си прав за малкото време на разработка - но има една подробност - трудната разширяемост на проекта - от което по-късно се губи много време. Ето защо Dephi (на настоящото ниво) не е подходяща платформа за огромни бизнес приложения. VS също - обикновено се ползват други платформи за разработка писани на споменатите.
5. Реално целия въпрос е политически повече отколкото технически - идеята е в цената и броя клиенти които можеш да привлечеш. Идеята да се влагат много пари в интернет и прочие приложения и компании които с 100 000 долара изведнъж се напомпват умря - за това е и кризата в момента. Ако успееш да предложиш на клиента достатъчно гъвкаво и финансово аргументирано решение - печелиш - но хората с много пари си правят добре сметката за какво ги харчат - и не ги дават лесно.
Т.е. много по лесно е да вземеш от 1000 човека по 50 лева за някаква малка програмка тип склад и фактуриране отколкото да накараш някоя сериозна фирма да ти даде тези 50 000 - примерно - последното важи за БГ пазара основно. Ако ти задължиш клиента да се хвърли на M$$$$$$ платформата и след 1 година му направят проверка и го накарат да киха по 5000- 30000$ на година само заради поддръжката на един MS SQL - не си струва - но вси4ко това си зависи от мащабите на дейността.
Всъщност това което казвам е доразвиване на идеята която ти започна - нищо друго.
---
Е т'ва е живот!
Re: Да де, ама
1. Относно кой и как не си сменя софтуера - може да спорим до утре, само ще спомена че компютрите на Запад имат срок на амортизация 3 години - демек за 3 години се предполага че стария комп отива на боклука и зимаш нов. Да подскажа ли че новия комп е с нови Прозорчета
2. За читава програма с валидация и прочее - в нашата фирма работим точно с това. Както можеш да видиш и примерите с Midas в Delphi 5 - а Midas се цели точно в корпоративния пазар.
3. Това за IE и MS сървър от другата страна не го разбрах - не виждам никаква смислена връзка между браузър и сървър в този контекст. С един браузер можеш да гледаш страници от всякакъв сървър. Що се отнася за thin клиент - администрирането на IIS и едно кило сървъри на M$ става без проблем през браузери. Да не говорим за .NET
4. За ISAPI-то и неговата трудна разширяемост - ама хич, хич, хич не си прав. Нашата фирма е една от многото която разчита на ISAPI - получава се строен обектен модел който може да се разплува колкото ти кефне. Само не споменавай че с Delphi и VS не се правели големи web приложения - точно с тях се правят, щото се гони бързодействие. VS-то е безпорно с най-голям пазарен дял при разработка на ISAPI, CGI и едно кило други модули за IIS. Посочи ми по-голям и имаш каса бира.
5. И накрая - бъдещето е показано много ясно - в NET-а. Т.е. не е идеята да праскаш програмки, за които трябва инсталиране, поддръжка, ъпдейти на всички клиенти и прочее. Затова е измислен клиент/сървър модела - правиш един сървър и си го развиваш както ти кефне, а на клиента оставяш грижата да си работи с него през един браузер. Това е много, много по-евтиното решение откъм поддръжка, дистрибуция и прочее. Натам се е насочил чичко Били, и вервай ми, той има още много милиарди да глътне.
Накрая - за парите. Пари при пари отиват. Трябва да се плаща - с пари, акъл или и двете, за да плащат на тебе. Така е по-света, и това че хората там си плащат софтуера не ги е направило бедни.
Бтв, отивам да пия бира. Лека вечер на всички.
чети и дишай по-леко
2. За читава програма с валидация и прочее - в нашата фирма работим точно с това. Както можеш да видиш и примерите с Midas в Delphi 5 - а Midas се цели точно в корпоративния пазар.
3. Това за IE и MS сървър от другата страна не го разбрах - не виждам никаква смислена връзка между браузър и сървър в този контекст. С един браузер можеш да гледаш страници от всякакъв сървър. Що се отнася за thin клиент - администрирането на IIS и едно кило сървъри на M$ става без проблем през браузери. Да не говорим за .NET
4. За ISAPI-то и неговата трудна разширяемост - ама хич, хич, хич не си прав. Нашата фирма е една от многото която разчита на ISAPI - получава се строен обектен модел който може да се разплува колкото ти кефне. Само не споменавай че с Delphi и VS не се правели големи web приложения - точно с тях се правят, щото се гони бързодействие. VS-то е безпорно с най-голям пазарен дял при разработка на ISAPI, CGI и едно кило други модули за IIS. Посочи ми по-голям и имаш каса бира.
5. И накрая - бъдещето е показано много ясно - в NET-а. Т.е. не е идеята да праскаш програмки, за които трябва инсталиране, поддръжка, ъпдейти на всички клиенти и прочее. Затова е измислен клиент/сървър модела - правиш един сървър и си го развиваш както ти кефне, а на клиента оставяш грижата да си работи с него през един браузер. Това е много, много по-евтиното решение откъм поддръжка, дистрибуция и прочее. Натам се е насочил чичко Били, и вервай ми, той има още много милиарди да глътне.
Накрая - за парите. Пари при пари отиват. Трябва да се плаща - с пари, акъл или и двете, за да плащат на тебе. Така е по-света, и това че хората там си плащат софтуера не ги е направило бедни.
Бтв, отивам да пия бира. Лека вечер на всички.
чети и дишай по-леко
Re: Да де, ама
Бидейки консервативен повече от необходимото ще се изкажа и аз по тая темичка:
1. Пишете си софтуера сами - веднъж като натрупате код зад гърба си и всичките ви проблеми отпадат. Аз в момента се радвам на собствен уеб сървър и собствен БД абстрактиращо ниво - което се цели в SQL и на места в TTable. Извикванията се правят от определен обект с 4-5 метода ако реша да мигрирам и има TDataSet компоненти за другата платоформа само сменям типовете от вида
type
TQery=TXXXXQuery;
TTable=TXXXTable;
иначе пренаписвам 100-тина реда и всичо спи.
2. Има задачи които могат да се решат клиент/сървър и има такива които немогат. Има такива които има смисъл да се решават така има и такива които няма смисъл. Пример за задача която няма смисъл е офис приложение. Пример за която не може да се реши е CAD/CAM
3. Не залягайте на M$ по на горе от API. Това да се ползва техния IIS ми се струва върхът на безумието. За MS-SQL - нямам наблюдения ама техния стил е много подобен на Oracle: "ако ще ни ползваш продукта първо ща изкаращ 6 месеца обучение иначе си за никъде...". За клиен/сървър ДБ-то няма нужда да може да се АДМИНИСТРИРА по начина който го разбират ИСТИНКИТЕ СУБД-та. Веднъж инсталирани таблиците са такива докато не се смени версията която си идва с новите таблици - сега за да избегнем писане на страничен бекъп да ползваме СУБД чудовище - аре нема смисал па и излиза доста соленко.
4. Недостатъка на всичко до тук е че ако в рекламата ви не пише изискав се наличие на MS-SQL, MS-IISx, Oracle X и не се позовавш на MIDAS, COM DCOM, .NET, CORBA и прочие просто РАЗБИРАЧИТЕ не те гледат с добро око а много разбирачи се навъдиха д'еба....
------------------------------
I got a COMPILER, and I'm not afraid to use it!
1. Пишете си софтуера сами - веднъж като натрупате код зад гърба си и всичките ви проблеми отпадат. Аз в момента се радвам на собствен уеб сървър и собствен БД абстрактиращо ниво - което се цели в SQL и на места в TTable. Извикванията се правят от определен обект с 4-5 метода ако реша да мигрирам и има TDataSet компоненти за другата платоформа само сменям типовете от вида
type
TQery=TXXXXQuery;
TTable=TXXXTable;
иначе пренаписвам 100-тина реда и всичо спи.
2. Има задачи които могат да се решат клиент/сървър и има такива които немогат. Има такива които има смисъл да се решават така има и такива които няма смисъл. Пример за задача която няма смисъл е офис приложение. Пример за която не може да се реши е CAD/CAM
3. Не залягайте на M$ по на горе от API. Това да се ползва техния IIS ми се струва върхът на безумието. За MS-SQL - нямам наблюдения ама техния стил е много подобен на Oracle: "ако ще ни ползваш продукта първо ща изкаращ 6 месеца обучение иначе си за никъде...". За клиен/сървър ДБ-то няма нужда да може да се АДМИНИСТРИРА по начина който го разбират ИСТИНКИТЕ СУБД-та. Веднъж инсталирани таблиците са такива докато не се смени версията която си идва с новите таблици - сега за да избегнем писане на страничен бекъп да ползваме СУБД чудовище - аре нема смисал па и излиза доста соленко.
4. Недостатъка на всичко до тук е че ако в рекламата ви не пише изискав се наличие на MS-SQL, MS-IISx, Oracle X и не се позовавш на MIDAS, COM DCOM, .NET, CORBA и прочие просто РАЗБИРАЧИТЕ не те гледат с добро око а много разбирачи се навъдиха д'еба....
------------------------------
I got a COMPILER, and I'm not afraid to use it!
Re: Да де, ама
Ми хайде по точки:
1. Ако тръгнеш да пишеш всичко сам, ще изгубиш прекалено много време. Никой няма да те чака да си напишеш сам базата, сам веб сървъра и прочее.
Миграцията от Access към MSSQL /и не само/ става с една импорт операция - вградена в повечето сървъри и преконструирането на един ConnectionStrig - с помощта на wizard - ако говорим за ADO де.
2. Целта на спора са точно клиент/сървърните решения, в които целта е много клиенти да имат достъп до една база.
3. Без да съм върл фен на M$, ще кажа много ясно - от програмна гледна точка IIS е безкрайно удобен сървър. Обектната му система е много удобна за автоматични инсталации, даване на привилегии и прочее. Аз например направих wizard за инсталиране на ASP приложение за около 1 ден, като самия код за създаване на виртуалната директория, даването на права за нея, проверка за съществуването и прочее се побира на един екран код - чисто и ясно. Абсолтно същото администриране може да се направи и през ASP например. Като добавим най-яката help система, мога смело да твъря че за IIS се пише най-продуктивно.
4. За всички знайни и незнайни съкращения - позоваването на тях има смисъл. Например ако си тествал бързодействието на Oracle, ако държиш кодът ти да може да се използва от програмисти не само на Delphi - чрез COM, ако не ти се иска да губиш много, много време за да пишеш сам трансфера на данни по различни протоколи - http, tcp/ip, ipx и прочее - можеш да се облегнеш на DCOM или CORBA, ако искаш бързо /от парични съображения/ да спретнеш многослойна система - един добър избор е MIDAS и т.н.
И накрая - никой програмист не бива да забравя, че не пише само за себе си. Съобразявайте се с другите - това ще ви носи само полза. Не всички стандарти са лоши - повечето от тях са измислени с цел да облекчават и съвместяват работата на много програмисти, повечето от които са по-добри в някои аспекти от вас. В крайна сметка програмирането е повече бизнес, отколкото изкуство - а във всеки бизнес има правила. Да се играе по тях не е признак на слабост и незнание, аз съм убеден в това.
чети и дишай по-леко
1. Ако тръгнеш да пишеш всичко сам, ще изгубиш прекалено много време. Никой няма да те чака да си напишеш сам базата, сам веб сървъра и прочее.
Миграцията от Access към MSSQL /и не само/ става с една импорт операция - вградена в повечето сървъри и преконструирането на един ConnectionStrig - с помощта на wizard - ако говорим за ADO де.
2. Целта на спора са точно клиент/сървърните решения, в които целта е много клиенти да имат достъп до една база.
3. Без да съм върл фен на M$, ще кажа много ясно - от програмна гледна точка IIS е безкрайно удобен сървър. Обектната му система е много удобна за автоматични инсталации, даване на привилегии и прочее. Аз например направих wizard за инсталиране на ASP приложение за около 1 ден, като самия код за създаване на виртуалната директория, даването на права за нея, проверка за съществуването и прочее се побира на един екран код - чисто и ясно. Абсолтно същото администриране може да се направи и през ASP например. Като добавим най-яката help система, мога смело да твъря че за IIS се пише най-продуктивно.
4. За всички знайни и незнайни съкращения - позоваването на тях има смисъл. Например ако си тествал бързодействието на Oracle, ако държиш кодът ти да може да се използва от програмисти не само на Delphi - чрез COM, ако не ти се иска да губиш много, много време за да пишеш сам трансфера на данни по различни протоколи - http, tcp/ip, ipx и прочее - можеш да се облегнеш на DCOM или CORBA, ако искаш бързо /от парични съображения/ да спретнеш многослойна система - един добър избор е MIDAS и т.н.
И накрая - никой програмист не бива да забравя, че не пише само за себе си. Съобразявайте се с другите - това ще ви носи само полза. Не всички стандарти са лоши - повечето от тях са измислени с цел да облекчават и съвместяват работата на много програмисти, повечето от които са по-добри в някои аспекти от вас. В крайна сметка програмирането е повече бизнес, отколкото изкуство - а във всеки бизнес има правила. Да се играе по тях не е признак на слабост и незнание, аз съм убеден в това.
чети и дишай по-леко