Forráskód strukturálása, logikai felépítése
2005-04-11T22:33:10+02:00
2005-04-12T00:38:24+02:00
2022-07-27T03:53:49+02:00
  • Hadd kotyogjak bele én is egy kicsit!

    A háromrétegű modell már sokszor bevált, kellően függetleníteni tudja az üzleti logikát mind az adatbázis, mind pedig a kinézet felé, tehát nem kell újraírni az egész cuccost ha kell még egy művelet, vagy még egy input mező valahová, úgyhogy szerintem érdemes minden vonalon (komponens, alkalmazás) követni ezt a felépítést.

    A feladványt komponensekre bontani azonban csak akkor van értelme, hogyha ezeket más aklalmazás vagy prokekt részeként is akarjátok majd használni, ehhez viszont ezeknek kellően általánosnak, egybezártnak és a rendszer többi részétől függetleníthetőnek kell lenniük.

    Pl. egy egyszerűbb partner adatbázis is lehet egy jól körülhatárolható és elkülöníthető, általános valami, azt tokkal vonóval (UI, BL, DAL) érdemes lehet külön tenni, mert esetleg egy további alkalmazásban szükség lehet rá (pl. kell egy közös törzs).

    (Lehet úgy is tervezni, hogy nem lesz belőle külön komponens, csak a lehetőségét hagyjátok meg, ha az tényleg szükségessé válna.)

    Számomra nem teljesen világosak az indokok, amik miatt ez ennyire szét van szedve. Nem tudom, hogy ez a feladvány majd mekkora szeretne lenni, de ha ennél nem sokkal nagyobb, akkor szerintem nem érdemes komponensekre szétvagdalni, hát még projektekre. A három réteg is inkább logikai elválasztás, mint névterekbe rendezés kellene, hogy legyen, ennyire kis osztályszám mellett szerintem még ez is (mármint a névtér) felesleges.

    Szerintem egy projekt az kb. egy futó alkalmazásnál vagy esetleg egy nagyon általános komponensnél kezdődik, de nem egy három osztály kódjával kitöltött dll-nél...

    Számomra ami még hiányzik, hogy az egész nem a feladatban meghatározott funkciók entitások és felületek szemszögéből, hanem túlzottan valamilyen önkényes strukturálás irányából van megközelítve. Az egyes osztályokat a hierarchiában nem nagyon köti össze semmi, pedig a nevük alapján vélhetőleg sokan összetartoznak. Pl. a Product.cs gondolom valamilyen termék lehet a rendszerben, ugyanakor a vélhetőleg hozzá tartozó ProductDataPage.cs teljesen másol van (gyakorlatilag minden más: projekt, komponens, névtér). Ez nekem nem nagyon tecc....
    Ezek szorosan összefüggő dolok, hiszen egy termék adatstruktúra változás értelmszerűen kihat az UI-ra és az adatkezelési rétegre, ezeknek egymás mellett a helyük...

    Amúgy van az UML és az RUP (egész pontosan az utóbbi) ami egész pontosan megmondja, hogy hogyan érdemes szétdarabolni a rendszert, de ha már terveztek, akkor az egész módszert érdemes végigolvasni.

    Persze ez mind csak az én nyomott véredényem...
    Mutasd a teljes hozzászólást!
  • Helló!

    Én első ránézésre nekde adnék igazat. Túl tapasztaltnak én sem mondanám magam, de azt hiszem nem sok programozó van, aki úgy állna hozzá mint a kollégád.
    (Persze lehet hogy van rá magyarázat, de ez vlaszeg inkább csak megszokás.)

    Először is, eszembe nem jutna így szétosztani a rétegeket.
    Nemtom a csatolt képen az egész rendszer látható-e, de feltételezve, hogy igen (a referenciák között nincs saját dll megadva), akkor a legnagyobb baj, hogy az egyes rétegek úgy vannak szétosztva, hogy semmi közös kódra nem épülnek, minden projectben implementálva van 1-1 komplett réteg. Nem értem miért, hiszen függetlenűl attól, hogy 'Folder'-hez vagy 'Product'-hoz kellenek az adatok, ugyanarra épűl az adatbáziskazelés. Ha rosszúl látom, és a refernciák között még van egy legalsó adatbáziskezelő réteg, akkor is logikusabb a te módszered szerint strukúrálni az egészet.

    Arról nem is beszélve, hogy az ő módszerével szvsz jóval nehezebb dolgotok lesz, ha egyszerre dolgoztok az ügyön (megosztva a forrás VSS-ben vagy ilyesmiben és nem csak magának kódol mindenki...)

    Ráadásúl ha téged át is szoktat az ő szemléletére (szerintem ne hagyd), a következő kollégát már nem biztos. Meg az azutánit, és így tovább. Annyit már én is megtanúltam, hogy ha mindemki magának programoz, úgy gondolja elég ha csak ő látja át, akkor régen rossz az egész.
    Mutasd a teljes hozzászólást!
  • Egy vitás kérdésben szeretném, ha segítenétek dönteni, még pediglen, hogyan érdemes egy forráskódot - jelen esetben C# ban - áttekinthetően strukturálni.


    Az én elképzelésem szerint, amit jó néhány neves szerző könyveinek átolvasása után fogalmazódott meg, a következőképpen lehetne áttekinthetően felépíteni a forráskódot.
    C# -ba ugye van a Solution, ami összefogja az egész alkalmazás forráskódját.
    Ezen belül lehet csoportosítani projektekkel, és névterekkel, majd osztályokkal ugyebár.

    Nos én alapul 4 projektet készítek a solutionba, ami a következő.

    1. Adatelérési réteg. Data Access Layer, amin keresztül tudom elérni kizárólag az adatbázist.
    2. Az adatelérési réteg fölé kerül az üzleti logikai réteg (Business Logic Layer, BLL). Ez a réteg kapja meg a felhasználói felületről érkező kéréseket és az alkalmazás működésének megfelelően a DAL segítségével, kiszolgálja azokat.
    3. Megjelenítési réteg. Ezekben találhatók, az un. Windows formok. Amiknek az üzleti logikáját a BLL - ben valósítom meg. Tehát ez által a megjelenítés függetlenné válik a program logikától.
    4. Általános réteg. Common Access Layer. Ezt a réteget a többi réteg is el tudja érni, ebben kapnak helyet az általános objektumok, pl. User, Client, Product, stb. objektumok.

    Ez a négy nagy projektem lesz a Solutionba. És a projekteken belül, meg névterekkel igyekszek strukturálni a forráskódot, amit a Solution Explorerben létrehozott folderekkel igen szemléletesen meg lehet oldani.

    ----------------------------------

    A másik elképzelés, ami a kollegámé a következő:

    Ő először, mikor észrevette, hogy a projekteket, a VS külön dll -be fordítja, szétszedte az egész alkalmazást projektekre, ami jelenleg, 10 projektet, foglal magába a következőképpen.

    Nem látom át teljesen, ezért beillesztem, amit ő írt róla:

    "Jelenleg az alkalmazásban az alábbi projekteket
    különítettem el:

    DAL - Ebben csak a Dal névtér van, de jelenleg 2 osztály (abból 1 duplán :)
    Még nem írtam át az átküldött doksinak megfelelően, de még ma meglesz.
    ENU - Employers aNd Users - Ebben az alábbi névterek vannak: Com.ENU Bll.ENU és Dal.ENU
    Customer - Ebben az alábbi névterek vannak: Com.Customer Bll.Customer és Dal.Cusomer
    Folder - Ebben az alábbi névterek vannak: Com.Folder Bll.Folder és Dal.Folder
    Product - Ebben (szerinem) az alábbi névterek legyenek: Com.Product Bll.Product és Dal.Product

    pamaba - ez maga az induló Windows interface, és a pmb névtérben van.
    Ebbe kéne majd az általános paneleket beletenni, amik közösek.
    pmbCustomer - ebben vannak az ügyfelek paneljei, pl az akta, adatlap, stb...
    névtere: pmb.Customer
    pmbOptions - ez a Windows beállítások panel, és annak összes alpanelje. névtere: pmb.Option
    pmbENU - ebben tulajdonképp a felhasználók és alkalmazottak aktái vannak. 1enlőre.
    névtere: pmb.ENU
    pmbList - ebben van az alap lista panel. 1enlőre. névtere: pmb.List
    pmbProduct - ebben lennének a termék adatlap és akta paneljei. Lásd :) névtere: pmb.Product
    "

    Tehát ő szétszedte, úgy, hogy külön projektekbe rakta, a különböző objektumokat, mint pl. User, Client, Product... És egy ilyen projekten belül valósította meg az adatelérési objektumát is.

    Ami nekem szembetűnik, hogy nincs átláthatóan strukturálva, alapjába véve nincs külön választva, hogy az azonos típusú objektumok, mint pl. azok, amik használják az adatbázist, egy csoportba legyenek foglalva, stb.

    És ami technikailag probléma, hogy mindig ki kell írnia az objektum teljes elérését, mert az objektumai, névterei ütköznek.

    Mivel én kezdő programozó vagyok légy szíves, segítsetek meggyőzni, arról, hogyha a kollegámnak van igaza, de ha nem, akkor plz. Segítsetek őt meggyőzni engem.

    itt le tudjátok tölteni a Soluton Explorerben látható képeket is.

    Solution Explorer
    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