Új hozzászólás Aktív témák

• #8839 dqdb nagyúr coco2 #8835

  Új Válasz 2019-07-27 11:32:28 #8839

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dqdb

  nagyúr

  válasz coco2 #8835 üzenetére

  így utólag már mezei file-ok és memória blokkok elegendőek az sql szerver helyett, ami bizony egyszerűbbé teszi a dolgokat - akár hiszed, akár nem.
  Tudom, hogy egyszerűbbé tudja tenni a fájlokat használó megoldás az életet, rendszeresen használok ilyet a storage interfész mockolására tesztekben. Persze éles környezetben nem, hiszen a redundancia, rendelkezésre állás kifejezések léteznek, és amíg egy clusterezhető middleware elintézi helyettem az adatok node-ok közötti replikálását, addig egy fájlalapú megoldásnál nekem kellene ezt nulláról lefejleszteni. Nem lehetetlen, csak rettenetesen időigényes, és akármennyi erőforrást is elégetek rá, akármennyi tesztet gyártok hozzá, a saját implementáció kevésbé lesz tesztelve éles szituációban, mint az elterjedt 3rd party megoldások. Vannak esetek, amikor érdemes feltalálni a spanyolviaszt, mert megéri, ez szerintem határozottan nem az.

  Részemről inkább azt a kérdést tartom nehezen megválaszolhatónak, hogy a c# topikban miért c stuffokat preferálnak a népek?
  Én sosem a nyelvhez, hanem mindig feladathoz választok middleware-t, az pedig, hogy miben írták, teljesen irreleváns addig, amíg van hozzá .NET vagy REST API. Így aztán az egyik rendszerünk tipikus telepítése használ Javában, Erlangban és Góban készített middleware-eket (másikban akad Ruby is), miközben a rendszerünk forrása egyetlen sornyi Javát, Erlangot és Gót sem tartalmaz. Nem azért, mert a szivárványos össznyelvi összeborulás volt a cél, hanem azért, mert adott részfeladatra az adott komponenst találtuk a legjobbnak.

Új hozzászólás Aktív témák