ORDBMS.NET
2006-06-18T11:08:39+02:00
2006-06-19T10:41:02+02:00
2022-07-19T05:52:02+02:00
  • Használható és támogatott! Nézd meg pl. a db4objects oldalát, hogy mennyien építenek erre. Nem éheznek a srácok, az 100.

    Nyilván nem lehet minden üzleti rendszert ilyen modellel ábrázolni. Főleg nem az olyan "vevő/termék/számla" féle rendszereket. Nem is erre való az egész. Hanem pont az olyan rendszerekhez, amiknek az üzleti modelljük (így a lekérdezések is) teljesen objektum-orientáltak. Ez esetben az RDBMS az erőszak, mert egy olyan dolgot használunk az implementációra, ami nem erre van kitalálva.

    Amúgy válaszolva: ha az ORDBMS rendszered SQL fordító (magyarul RDBMS-t használ, nem natív object rendszer, mint a db4objects), akkor ugyan úgy hozzá tudsz férni sima SQL-lel minden információhoz, mint ha csak RDBMS-t használnál. Ezért nagyon jók és életképesek ezek a fajta rendszerek, mert igazából a legtöbb üzleti modellhez a hibrid megoldás a nyerő. Sz'al fejlesztik gőzerővel a LinQ-et az MS-nél. Most úgy állnak, hogy a 3.5 FX-ben adják ki (magyarul a Vistában még nem lesz benne, csak egy update-ben ). Ezért kell nekünk szenvedni egy saját implementációval addig is.

    (halmozott szóismétlés: EGYES!)
    Mutasd a teljes hozzászólást!
  • Nekem eleve a koncepcióval van bajom. Pontosabban lehet hogy csak én értem félre a dolgokat, de én ezeket úgy értelmezem hogy egy az egyben csináltnak táblából üzleti objektumot. Azaz ha nekem kell egy termék akkor szépen előszedi a rendszer a termék objektumot a vevő táblából és én ezen hajthatok végre különféle műveleteket. Viszont ez így ebben a formájában szvsz nem a legjobb ötlet. Ugyanis az esetek jó részében nem kell az egész objektum, csak mondjuk a termék neve és az ára, de mondjuk a képe már nem. Vagy ezek az OR-mapping rendszerek tudnak olyat is hogy egy fizikai tábla egyes mezőit több objektumtípusba is le tudják képezni ?

    Amúgy engem is érdekel a dolog, a wikipédiának az angol nyelvű verziójában felsorolnak pár OR-Mapping rendszert, elég sok open-source-ot is, de hogy mi mennyire használható vagy támogatott az nem derül ki.
    Mutasd a teljes hozzászólást!
  • Háály!

    Sok feladat esetében jobban jár a fejlesztő, ha relációs SQL rendszer helyett vmi ORDBMS megoldásban gondolkodik. Sokat gyorsulhat a fejlesztés és a kód sebessége is, ha ténylegesen objektum-orientált a z "üzleti logikája" a projektnek.

    Épp egy ilyen projekt tervezési fázisában vagyunk a cégemnél. .NET-es környezetben fejlesztjük a rendszert, és épp ott tartunk, hogy milyen ORDBMS megoldást használjunk fel ehhez.

    Némi felhalmozott tapasztalat:

    db4objects: Az ideális megoldás! Egy natív objektum-orientált adatbázisrendszer, szóval nem SQL-re fordítja az OOP query-ket, hanem teljesértékü adatbázis megoldás. Mindent támogat, amit egy mai adatbázis-szervertől elvárhatunk (tranzakciók, schema versioning, stb); és piszok gyors az egész, főleg az SQL fordítókhoz képest. Ráadásul mindenféle mező/property attribútum bűvölés helyett, teljesen automatikusan tárol minden natív .NET objektumot. További információk: itt.

    Az egytelen hátránya csak annyi, hogy olyan csillagászati összegbe kerül, amit az egyszeri magyar vállalkozás egyszerűen képtelen megfizetni. Kértem tőlük egy árat a köv szituációra: vagy egy 2 procis adatbázis szerver, ami kiszolgál egy webes UI-t, plusz több kliens oldalon futó adatmanager+spec. progit (WebService-n keresztül). Erre összvissz EGY DB DLL kellett volna. Na most ennek az ára magyar pénzben 600e+ÁFA/év lett volna. Igaz, hogy ehhez jár a teljes support+miegymás, de a projekt annyit nem tud termelni az első pár évben, hogy ekkora szoftver inveszt pluszt is elbírjon a dolog (az eddigi vonzata: vas+Win2003/szerver+kliensek+MSSQL szerver+a fejlesztéshez VS2005-ök, 1db 3ds MAX,Adobe Premiere-k,Photoshop-ok, stb, stb, mert egy webes multimédiás projektről van szó)...

    DLinQ: Még nem adtak ki olyan verziót, amivel el lehetne kezdeni az érdemi melót, pedig ígéretesnek tűnik a dolog. Az előzetes verzió még mindig nem támogatja a polymorphic query-ket.

    Borland ECO: Lassú, lassú, lassú, nagy, bonyolult (UML gány, sima osztálydeklarációk helyett ), és a Borland most épp saját magával van összeveszve, tiszta fejletlenség az egész cég ahhoz, hogy egy induló projektet bárki nyugodt szívvel az ő megoldásaikra bízza.

    Az sem tett nekik túl jót, amit a BDS 2006-tal műveltek. Kiadták 2005-ben 1 hónappal a .NET 2.0 megjelenése előtt .NET 1.1 támogatással ; a dobozok harmadára az volt rárajzolva, hogy Borland C++ Builder 2006, közben jobban járt volna bárki egy sima Notepad-del C++-os fejlesztésekhez, és ezen az állítólagos javítócsomag sem tudott sokat segíteni, stb, stb...

    NHibernate + egyes Java-s átíratok: lassú, platformidegen, összedobált rendszerek.

    Szóval most ott tartunk, hogy fejlesztünk egy absztrakciós réteget (~ interface-k) úgy, hogy a legutóbb az MS blog-on ígért DLinQ képességeihez mért dolgokat kezeljen, és a megvalósításhoz -átmenetileg (a DLinQ megjelenéséig) egy saját, a Gentle.NET-re épülő motort használunk. Muszáj ez a félmegoldás, hiszen mire az MS kiadja a saját rendszerét, addigra nekünk már fel kell mutatnunk a concept-et + némi működő dolgot.

    Kíváncsi lennék a Ti tapasztalataitokra is ORDBMS + .NET ügyben!

    (meg van az oka annak, hogy miért az MS platformot választottuk, ebbe most ne menjünk bele; szóval az ezt firtató hozzászólók kíméljenek)
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd