Kiedy starałem się o pracę w Internet Center Polska półtora roku temu, w ramach kwalifikacji zostałem posadzony przed komputerem i dostałem za zadanie napisanie w PHP panelu do zarządzania prostą, jednotabelową bazą danych. Dziś byłbym w stanie to zrobić w ciągu kilkunastu minut i całość zawrzeć w pięciu liniach kodu.
Od roku coraz większą popularnością cieszą się frameworki implementujące CRUD jako przezroczystą automatykę, rewolucję zaczął znany dziś wszystkim silnik Ruby on Rails. Cała idea polega na odseparowaniu właściwego kodu aplikacji (model, kontroler) od warstwy najniższego rzędu, odpowiadającej za przechowywanie danych (storage). Ta ostatnia jest obsługiwana automatycznie przez silnik, wystarczy zatem stworzyć odpowiednie tabele w bazie danych i zadeklarować wzajemnie relacje pomiędzy obiektami — sprowadza się to do dopisania właściwych słów kluczowych do klasy modelu.
Po krótkim prototypowaniu połączeń, silnik staje się zupełnie przezroczysty. Można wykonywać dowolne operacje na instancjach poszczególnych klas, a każda zmiana zostanie natychmiast odzwierciedlona w zawartości bazy danych. Odpada konieczność pisania zawiłych zapytań SQL, wzrasta też elastyczność kodu (staje się niezależny od struktury poszczególnych tabel — po dodaniu nowego pola, nie ma potrzeby modyfikacji kodu odpowiedzialnego za obsługę tabeli).
Oczywiście, Rails nie jest jedynym frameworkiem tego typu. W jego ślady poszli deweloperzy korzystający z innych języków programowania. Dziś szkielety podobnych lub identycznych rozwiązań dostępne są dla większości z popularnych języków. Najczęściej stosowany w aplikacjach małego i średniego kalibru, PHP, ma ich nawet kilka. Szczególnie interesujący jest jednak jeden z pierwszych, dostępny od zeszłego roku CakePHP — tutaj nawet słowa kluczowe (w PHP reprezentowane przez zmienne) są żywcem zaczerpnięte z pierwowzoru.
Kiedy warto stosować CRUD? Odpowiedź jest prosta — kiedy tylko się da. Oczywiście, nikt nie zbuduje w ten sposób wydajnego systemu bankowego, ale większość tworzonych aplikacji to rozwiązania z niższej półki — aplikacje ekstra-/intranetowe, systemy CMS i dynamiczne witryny internetowe. Biorąc pod uwagę, że proces tworzenia oprogramowania ulega kilkunastokrotnemu skróceniu i staje się bardziej odporny na błędy, korzyści są nie do odrzucenia.
Technorati Tags: webapp, code, crud, ruby, rails, php, framework
tja, scaffolding rządzi :)
a co do frameworków w php - ostatnio urzegło mnie symfony (http://www.symfony-project.com/)
Chyba jeszcze bardziej podobne do Rails jest TRAX, chociaz odnosze wrazenie, ze projekt jest troche mniej dojrzaly od CakePHP. Zdecydowanie brakuje tez dokumentacji.
Czemu mam wrażenie że właśnie przeczytałem jakieś farmazony ? To o czym piszesz jest od dawna znane, ogólnie przyjęte i usystematyzowane, a Ruby on Rails nie był żadną pod tym względem innowacją.CRUD od “Create, Read, Update, Delete” to też nie jest nic, co wprowadziłby Ruby on Rails. Nie rozumiem tego tekstu.
Rany boskie, Krzak! I ty ten belkot wklejasz na kanalii? RoR wymyślił CRUD? Frameworki CRUD? CRUD separuje warstwy aplikacji? Przezroczysty silnik? ;-) A komentarzach dodatkowo: scaffolding == CRUD. Jeszcze napiszcie, że wam ten CRUD robi, za przeproszeniem, laske.
krzak:
Gdzie ja napisałem, że CRUD wymyślił RoR. Czytanie ze zrozumieniem nie boli - Rails rozpoczął manię CRUD tak jak AJAX rozpoczął manię XMLHttpRequest. Z całym szacunkiem, od czytających oczekuję minimum zdolności do parsowania tekstu pisanego.
A rola CRUD jest dokładnie taka, żeby był przezroczysty, więc nie wiem, do czego pijesz.
O Ajaksie też nie wolno mi pisać, bo Garrett nie wynalazł XML? Ja prowadzę bloga o sieci, a nie o innowacjach technologicznych wynalezionych minutę temu.
Ja już sam nie wiem: laske w sensie laskę, czy łaskę, bo piszesz bez pl-literek? ;-þ
Patrys:
Z calym szacunkiem, ale zastanow przy czym obstajesz. Nie masz racji. RoR nie rozpoacza zadnej manii CRUD. Pozatym za CRUD nie kryje się żadna idea, żadna głębsza myśl. To jest akronim i nic więcej. Proponuję poczytaj o MVC na początek, i ogólnie o design patterns i odkryjesz że to co ty nazywasz CRUD to jest czym innym, i że zanim pojawil sie RoR to te metody były już bardzo szeroko wykorzystywane.
krzak:
Bzdura. CRUD to akronim, za którym kryje się przezroczysty silnik storage. Nic więcej. Ma to się nijak do MVC, bo model, widok i kontroler znajdują się ponad wartswą składowania danych. Model korzysta z silnika bazy danych, ale nie musi go zawierać i właśnie czwarta warstwa, storage, się tutaj pojawia. A czy używająć dynamicznego skryptowania bazy na podstawie jej struktury, zdecydujesz się na oddzielenie od siebie warstw MVC ma się nijak do tego, czy musisz w kodzie preparować zapytania do bazy. Dlatego też twoje powyższe komentarze i komentarz o scaffoldingu mają się nijak do notki.
A zanim znów mnie wyślesz na poszukiwania definicji MVC — od lat żyję z budowania aplikacji webowych i od lat używam silników templatowych i routingu do oddzielenia tych trzech warstw.
Ano, za CRUD nie kryje się nic więcej poza czterema wyrazami rozwinięcia. A to że modne ostatnio webowe frameworki MVC — a raczej o/r mappery, z których korzystają — siłą rzeczy CRUD implementują, do tego epatują demami, które scaffoldując kontrolery, budują “aplikacje” z prędkością niewiele mniejszą od prędkości operacji na dysku, nie czyni z CRUD idei rewolucyjnej. Ba, nawet trudno chyba mówić w tym kontekscie o jakiejkolwiek znaczącej idei.
W tej “rewolucji” już bardziej chodzi o sam scaffolding, czyli to co sprawia, że można przypiąć tym frameworkom etykietkę “rapid developement” (przynajmniej w zamierzeniu autorów), ale to o wiele więcej niż CRUD.
IMHO drugi akapit (a może nawet cały artykuł) miałby trochę sensu, gdyby podmienić CRUD na MVC.
mcv: Oczywiście, że laskę — synonim panaceum na wszelkie bolączki tego świata. ;-P
I CRUD i MVC jako pomysły są o lata starsze od Railsa i jego naśladowców. Ale o ile MVC każdy sobie jakoś implementował, to niewiele języków/silników/szkieletów pozwalało na tak wygodne zarządzanie bazą danych. Kiedyś szukałem podobnego narzędzia i byłem zmuszony napisać sobie brzydki component factory, który do konstrukcji klas używał eval().
Razem z RoR, oprócz wodotrysków, Ajaksa i powszechnego scaffoldingu przyszedł bardzo wygodny silnik do obsługi baz danych. Dowolne dane można sobie pobrać, zmienić i zapisać, operując tylko i wyłącznie na instancjach klas, bez pisania zapytań. To też nie jest rewolucyjna idea, ale od tego czasu nowe jej implementacje powstają jak grzyby po deszczu, nie tylko w klonach Railsa.
I tylko o tym jest powyższy tekst.
Wprawdzie wprowadzaniu systematyki blizej jest zwykle do teorii niz praktyki, ale CRUD to raczej pewien stereotyp use-case’a(*), który sprowadza się do wykonania operacji C/R/U/D [1] i zdecydowanie może być implementowany w jakikolwiek sposób (abstrakcja obsługi trwałości danych to inna bajka). Przeźroczystość obsługi warstwy danych to raczej wzorzec projektowy DAO (Data Access Object [2]), który często i gęsto występuje w samej specyfikacji J2EE, ale jest popularny także w innych technologiach. Temu, o czym piszesz, czyli generowaniu SQL w dialekcie wybranego RDBMS na podstawie mapowania klas i relacji na tabele najbliższe jest pojęcie O/R mapping, które w J2EE ma już za sprawą EJB, Hibernate, JDO i wielu, wielu innych rozwiązań kilka ładnych lat i jest niezwykle często stosowane, ale choć jest elastyczne (przede wszystkim w miarę niezależne od dialektu SQL, więc i wyboru samego RBMDS), to są przypadki, gdy rozwiązanie odwrotne, czyli tworzenie struktury obiektowej na podstawie struktury relacyjnej jest po prostu lepsze - zwykle wtedy, gdy migrujemy jakąs rozbudowaną aplikację z rozwijaną przez lata bazą produkcyjną na nową technologię, na przykład bazę DB2 z aplikacji RPG na J2EE. Z drugiej strony nadal ma sie dobrze “klasyczna szkoła”, czyli pure SQL po stronie aplikacji i procedury składowane na serwerze bazy danych - zdecydowana większość aplikacji .NET jest tak realizowana, przede wszystkim z uwagi na dobrze zgraną parę .NET & SQL Server, poza tym spadek wydajności w przypadku zupełnego niewykorzystywania procedur składowania może czasem być niedopuszczalny.
(*) jeśli CRUD wśród ludzi związanych z php oznacza jednak coś innego to proszę o zwrócenie uwagi, bo ja nie znaju tego gaju
[1] informatyczne definicje w wikipedii są beznadziejne, ale: http://en.wikipedia.org/wiki/CRUD_%28acronym%29
[2] http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
@parapsychopatolog lamalutomski radzi: ale CRUD za diabła nie ma nic wspólnego z O/R mapperami oprócz tego, że O/R mappery, podobnie jak bezpośrednie zapytania SQL, mogą implementować operacje CRUD
Być może nie jest do definicja książkowa, ale CRUD przyjęło się określać w skrócie wrappery silników baz danych.
m: toż piszę, że jedyne co ma wspólnego CRUD z “rewolucją” modnych frameworków, to to, że został tam gdzieś zaimplementowany. Z konieczności zresztą. Trudno w takim razie posądzać CRUD o bycie siłą napędową tej “rewolucji” albo umieszczać go na jej sztandarach. Poza tym pisałem, że uważam, iż ten piękny akronim został niefortunnie użyty, bo cały sens artykułu jakoś tam do mnie przemawia, jeżeli zmodyfikuje sobie część użytego nazewnictwa.
Patrys:
A mógłbyś jakiegoś linka zapodać? Skrót CRUD od wielu lat stosowany jest właśnie na etapie specyfikacji przypadków użycia do kategoryzacji use case’a jako operacji c/r/u/d na pewnym zakresie danych - o technologii czy implementacji na tym etapie nie ma mowy, anale takie rzeczy klepią. Jeśli te wrappery, o których mówisz, realizują dostęp do danych, a wypluwają obiekty, to jest to DAO. Jeśli ten dostęp jest realizowany poprzez SQL z wykorzystaniem mapowania obiektowo-relacyjnego to mamy wtedy O/R mappera, którego stosowanie może mieć wiele zalet, ale też wiele wad w zależności od wymagań i specyfiki rozwiązania. Największy ból przy stosowaniu O/R mapperów pojawia się przy rozbudowanych systemach, bo po pierwsze ich interfejsy udostępniają dużo mniejsze możliwości filtrowania danych i ich wstępnego przetwarzania niż RDBMS-dependent SQL, po drugie spada wydajność, po trzecie w przypadku konieczności wykorzystania istniejącej bazy gra przestaje być warta świeczki. Ale zalety, szczególnie w przypadku mniejszych systemów, są naprawdę ogromne. Fajnie, że w php pojawiają się takie rozwiązania i że o nich piszesz, bo porządkują one bardzo implementację, a php zachęca trochę do śmiecenia w kodzie. Być może właśnie dzięki upowszechnieniu się O/R mappingu w php wiele aplikacji pisanych dotąd wyłącznie dla MySQL zacznie być dostępnych także z innymi silnikami baz danych? Byłoby super!
m: zupełnie się zgadzam. I jednoczeście stanowczo protestuję przeciwko przypinaniu etykietki CRUD do wszystkiego, co się nawinie a dotyczy z grubsza przekrojowi MVC, O/R mapping i scaffolding. Sorry, ale jeżeli czytam, że CRUD separuje warstwy i zapewnia “przeźroczysty silnik”, to to ewidentnie zajeżdża egzaltacją PHP-owca, który nagle odkrył, że nie musi już przeklejać tego samego zapytania w dziesięciu plikach swojej “aplikacji”.
parapsychopatolog lamalutomski radzi:
ale funkcjonalność CRUD była implementowana z powodzeniem 30 lat temu w COBOL, bo nie sprowadza się do abstrakcji dostępu do danych, ale do stworzenia w jakikolwiek sposób funkcjonalności służącej do wykonania operacji c/r/u/d…
Oops. s/dotyczy z grubsza przekrojowi/odpowiada z grubsza przekrojowi/ :-)
parapsychopatolog lamalutomski radzi:
sorry za ostatni comment skierowany prosto w Ciebie - pomyłeczka ;)
m: nie mów tego mi, tylko autorowi artykułu, który stara się nas przekonać, że CRUD odkryto dwa lata temu, a do tego zapoczątkowano tym jakąś rewolucję. ;-)
Dobra, zgadzam się, CRUD to zbyt ogólne pojęcie, ale nie jest to też MVC, bo leży gdzieś na dnie modelu, a z widokiem i kontrolerami nie ma związku wcale.
Tak, znam pojęcia CRUD i DAO na poziomie planowania logiki. W mowie potocznej (może kwestia środowiska — nie, nie żyję w kraju pehapowców) CRUDem oznacza się właśnie dynamiczne budowanie klas dostępu dla obiektów danych.
Wypraszam sobie Poziom intelektualny dyskusji utrzymajmy powyżej twojego komentarza.
Gdzie ty byłeś, że nauczyli cię pisać, a czytać nie uczyli?
m:
Co do nazewnictwa: spora część grona webdevów nie studiowała kierunków stricte pozwiązanych ze składowaniem i przetwarzaniem informacji, dlatego nie zastrzegam sobie słuszności nazywania tego w ten czy inny sposób. To trochę jak z Ajaksem, który sam nie znaczy nic, a w praktyce nazywa się tak XmlHttpRequest.
@parapsychopatolog lamalutomski radzi:
Heh, wiesz… wytwarzanie oprogramowania to ogromny kocioł, do którego ciągle dorzucane są nowe rzeczy, a stare zlepiają się w nowe. Człowiek uczy sie całe życie. Sam zajmuję się na codzień rozwiązaniami J2EE, ale staram się poznawać pomysły architektoniczne stosowane w dużych aplikacjach .NET, czytać niusy związane z innymi branżami, subskrybuję też w ramach ciekawostek wiecznie żywą comp.lang.cobol :). Mignęło mi też jakos rok temu kilka informacji popularyzujących O/R mappery w php i to świetny news, bo może wreszcie pehapowcy dostrzegą potrzebe wspierania innych silników niż MySQL, który pomalutku jest podkupowany przez Oracle.
A sformułowanie “zajeżdża egzaltacją PHP-owca” jest akurat nietrafione, bo Patrys z niejednej technologicznej rzeki wodę pił, swoją wiedzę ma, o inteligencji potwornej nie wspomnę. Osobistych uwag warto unikać, bo się może w każdej dyskusji nieprzyjemnie zrobić.
@Patrys:
That’s true. Warstwę DAO lokuje się właśnie na dnie Modelu, między logiką biznesową a bazą danych, między którymi przelatują klasy trwałe.
I zupełnie inna kwestia: korzystałeś kiedyś z Zend Studio? Dobre to? Może mógłbyś o tym napisać i wypunktować miejsca przewagi nad vi? ;)
Patrys: no szur, jasna sprawa - wszystko jedno, jak ona sie nazywa, wazne, zebysmy wiedzieli, co nam moze dac ;)
Patrys, a coś mówiłeś o poziomie. ;-) Nie wycofuj się. :-) W wizji świata, którą przedstawiłeś, idea CRUD tkwiła w uśpieniu aż odkryto ją wzniecając rewolucję nowych, wspaniałych “frameworków CRUD”. Tak pisałeś jeszcze chwilę temu w artykule. Nie przekonuje mnie to. Podałem parę powodów i wątpliwości, m.in niefortunne nazewnictwo. To co poźniej napisałeś w komentarzach na temat “epoki pre-RoR” zabrzmiało tak, jakbyś utkwił w geccie pewnego języka i paradygmatu budowania aplikacji webowych i stąd to nagłe zachłyśnięcie. Nie znam Cię, mogę się mylić, ale tak to zabrzmiało. No offence.
Z mojej strony EOT, M wyczerpująco wyjaśnił istotę CRUD.
m:
Tak, jasne że używałem, ale nie miałem — niestety — możliwości skorzystania z enterprise’owego serwera analizy kodu z debuggerem, który jest tylko w najdroższej wersji. A bez niego to tylko taki ładniejszy notatnik i zajmuje więcej miejsca na ekranie.
Możliwości ma dużo, ale interfejs jest strasznie nieprzystępny i toporny. Trzeba się na początku przymuszać, żeby się nauczyć go używać. Nie wspomnę o używaniu efektywnym. Z niewątpliwych zalet — wieloplatformowość, ale to ma też jEdit.
parapsychopatolog lamalutomski radzi:
Nie tak napisałem, tylko tak chciałeś to zrozumieć. Krzak też. W moim tekście o ani nic nie ma. Jest za to o ewolucji frameworków do szybkiej budowy aplikacji webowych.
Ech, miało być EOT, ale nie mogę się powtrzymać zanaczyć po raz kolejny, iż od pewnego momentu odnosiłem się do Twojego komentarza, bo temat nazewnictwa CRUD uznałem za wyczerpany. Poza tym o odkryciu pisałem tylko w kontekście implementacji CRUD (zaznaczam: w Twoim rozumieniu, nie wracamy już do dyskusji na temat nazewnictwa), której Twoim zdaniem przed RoR nie było.
EOTEOTEOT
A jeżeli chodzi o początki tej dyskusji, to oczywiście, że się perfidnie czepiliśmy z krzakiem tego CRUDa ;-P
Zmieniając nudny temat… fajnie, że wspominasz o rekrutacji do ICP polegającej m.in. na napisaniu kawałka kodu, który coś robi. Kiedyś dyskutowaliśmy tutaj o różnych metodach rekrutacji, o pomysłach Joela Spolskyego, który uważa napisanie kawałka kodu podczas rozmowy za konieczność [1]. Ostatnio czytałem polskie wydanie jego książki “Zarządzanie projektami informatycznymi. Subiektywne spojrzenie programisty” [2] i choć nie zgadzam się w pełni ze wszystkimi “poradami”, to jest to miła lektura do kibelka, która przydałaby się wielu project managerom, szeregowym developerom także - Joel pracował w Microsoft, ma wiele ciekawych spostrzeżeń. Tyle, że Joel jest fanatykiem C i jego fascynacja wskaźnikami jest co najmniej zastanawiająca - choćby dla mnie napisanie kawałka bardziej sytego kodu w C byłoby problemem, bo gcc odpalałem ostatnio ze 3 lata temu. Z drugiej strony dużym problemem podczas pracy zespołowej są ci programiści, którzy tworzą śmietnikowy kod, z którym po jakimś czasie zrobić nie da się zrobić nic więcej niż napisać od nowa. Może by więc podczas rekrutacji dawać kandydatom kawałki takiego gównianego kodu do refaktoryzacji, żeby zobaczyć, jakie mają wyobrażenie o “dobrym kodzie” i jak ich znajomość języka pozwala na analizę kodu?
Ale i pomysł z napisaniem większego kawałka kodu, który coś robi, choć wymaga większej ilości czasu (ile zajęło to w ICP?) bardzo mi się podoba, bo lepiej sprawdza wszystkie aspekty tworzenia kodu.
[1] http://www.joelonsoftware.com/articles/fog0000000073.html
[2] http://www.merlin.com.pl/frontend/towar/409105
Offtopic:
m:
Jest nawet lepiej — w PHP 5.1 wbudowana jest nowa warstwa dostępu do baz danych, PHP Data Objects, która nie tylko wrapuje poszczególne silniki do wspólnego interfejsu, ale dodatkowo wymusza na sterownikach emulację funkcji, których nie wspierają same silniki baz danych. Dzięki temu można sobie na przykład korzystać do woli z preparowanych zapytań.
Problemy tutaj to nie tylko sam język i jego funkcjonalność. Spora część programistów PHP to tak zwani , którzy znają trzy konstrukcje językowe na krzyż i jedyną słuszną metodę dostępu do danych. Spora część programistów nie zna nawet podstaw projektowania systemów bazodanowych — spróbuj spytać się kogoś, w której postaci normalnej jest jego baza danych? Problemem jest też sama popularność języka — PHP zaczynał jako bardzo prosty język nastawiony na pisanie prostych scriptletów inline w kodzie HTML. Z czasem stał się potężną platformą do programowania obiektowego, ale po sieci i po księgarniach ciągle krąży bardzo marna literatura. Większość książek jest albo zdezaktualizowana, albo pisana przez ludzi, którzy wychowali się na PHP 3 i utknęli na tym etapie. Zmienne globalne, programowanie proceduralne, tona i obejścia na problemy, które od lat nie istnieją.
To samo powoli zaczyna dotyczyć .NET i ASP.NET — wyszukaj sobie dziesięć serwisów opartych na tej platformie i spróbuj pobawić się URLami albo formularzami — co najmniej połowa jest podatna na SQL injection, bo nikt nigdy nie nauczył tych ludzi, po co się cytuje i escapuje zapytania bezpośrednie i dlaczego lepiej zastąpić je preparowanymi.
Na zaglądam regularnie :)
Co do egzaminu - ja miałem na to jakieś trzy godziny i trochę więcej wymagań niż obsługiwanie dodawania, edycji i usuwania rekordów. Trochę czasu zajęło mi też upodobnienie KDE do GNOME, żebym mógł w ogóle patrzeć na monitor ;)
Patrys:
Super sprawa - świetnie, że włączyli to standardowo do języka, to najszybszy sposób na popularyzację. Byłoby naprawdę bardzo fajnie, gdyby z czasem najbardziej znane aplikacje pehapowe zaczęły być migrowane do tego rozwiązania. Przywiązanie pehapowców do MySQL nadal wydaje się ogromne.
Długo też tak myślałem, ale w ostatnim czasie Microsoft naprawdę się zmienia. Z ich ostatnich produktów naprawdę spodobało mi się Visual Studio Team System [1], które jest zintegrowaną platformą do testowania aplikacji, obsługi błędów, kontroli wersji i zarządzania projektem, mającą gonić funkcjonalnością IBM-owskiego Rationala. ASP.NET 2.0 i sam .NET 2.0, a przede wszystkim IIS 6 i Visual Studio 2005 kosmicznie upraszczają autoryzację i autentyfikację, po prostu zarządzanie bezpieczeństwem - samo tworzenie aplikacji webowych też staje się arcyproste, bo sporą część wykonuje się wizualnie. A sam Microsoft, obiecując kilka lat temu zadbanie o bezpieczeństwo, coś stara się jednak w tym kierunku rzeczywiście robić, nie zostawia też developerów samych sobie z codziennymi problemami i publikuje wiele “best practices” [2]. To chyba nie problem technologii, a generalnie świadomości istnienia pewnych problemów - akurat ASP.NET jest niezwykle popularną technologią do rozwiązań intranetowych, gdzie kwestie bezpieczeństwa są traktowane mniej poważnie niż w przypadku otwartych systemów. Z drugiej strony Microsoft na swoich konferencjach często mówi o bezpieczeństwie, wykłady o zapobieganiu SQL Injection też się pojawiały, a to naprawdę budujące, że Oni widzą taki problem. W każdym razie - warto o tym wszystkim rozmawiać, warto mówić, bo podręczniki uczące pisania bezpiecznych aplikacji czy poświęcone projektowaniu nadal są pewną egzotyką w porównaniu z podstawowymi podręcznikami do języków programowania. A nauka na poznaniu języka przecież się nie kończy. Ewangalizatorów nam trzeba. Dlatego fajnie, że piszesz :).
btw, zdjęcie z dwoma księgami mojżeszowymi, które kiedyś wrzuciłeś, było arcyzajebiste :)
[1] http://msdn.microsoft.com/vstudio/teamsystem/
[2] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch12.asp
[3] http://msdn.microsoft.com/practices/
Bzdura. CRUD to jak wiemy akronim od create, read, update, delete. I nie jest to wrapper bazy danych. CRUD to nazwa zestawu operacji na rekordach i wiekszosc tekstow z wpisu to powazne farmazony jak wspomnieli poprzednicy. Najprostszym przykladem idei pod nazwa CRUD sa obiekty oparte o wzorzec ActiveRecord badz genericObject gdzie kazdy obiekt reprezentuje pojedynczy wiersz w tabeli bazy danych. I takowy obiekt ma wbudowane metody do dodawania, usuwania, update i innych bajerow. To jest CRUD !! Wzorce AC oraz GO sa znane od dosc dawna - miejscami sie kryja pod inna nazwa, ale tak czy tak to jest wlasnie CRUD.
autopoprawka:
[2] = [2,3]
księgami = tablicami (czy jakoś)
;)
NuLL:
Sprawa już dawno wyjaśniona, spojrzenia na problem zintegrowane - nie ma co się burzyć, lepiej kolację zjeść niż nic nowego do dyskusji nie wnosić.
wszyscy sie mylicie
mialo byc:
wszyscy sie mylicie
crud.org