Jump to content
php.lv forumi

Konfigurācijas glabāšana


F3llony
 Share

Recommended Posts

Miljards gadus vecs topiks, bet nule atkal kļuvis aktuāls. Domāju un nevaru izdomāt, un šeit nu ir saraksts ar visām opcijām, kas vien ienākušas prātā.

 

PHP masīvi failos

<?php 
return [
  'a' => 1,
  'b' => 2
];

Pros:

  • Smieklīgi fleksibls (tas ir PHP fails, duh)
  • Opcached
  • Dikti ātrs

Cons: 

  • Nolāpītie masīvi

JSON

{
  "a": 1,
  "b": 2
}

Pros:

  • Vari dalīties ar konfigiem offline ar citām platformām (kura gan neatbalsta džeisonu?)
  • Diezgan viegli lasāms

Cons:

  • Lēnāks
  • Diezgan tizli rakstāms

YAML

---
  a: 1
  b: 2

Pros:

  • viss, kas JSON + vēl vieglāk lasāms

Cons:

  • Lēns kā suns

INI

[config]
a=1
b=2

Pros:

  • ātrāks par JSON un YAML

Cons:

  • tikai 2 līmeņi

PHP objektu konstantes

<?php 
class Config_Foobar
{
  const a = 1;
  const b = 2;
}

Pros:

  • nav tika fleksibls, kā PHP masīvi - tikai konstantas vērtības
  • opcached
  • dikti ātrs
  • tu vari izmantot autoload
  • IDE autocomplete

Cons:

  • konstantas vērtības (moš tas ir labi?)
  • viens līmenis (izņemot, ja tu esi lielisks un lieto 5.6, tad tu vari tur iebāzt arī masīvus)

Ja 5.6+, tad mans personiskais favorīts. 

 

PHP Objektu statiski propi

 

Tas pats, kas konstantes, tikai tupāka sintakse un nevajag 5.6.

 

 

Thoughts? Konstruktīvas idejas?

Edited by F3llony
Link to comment
Share on other sites

  • Replies 30
  • Created
  • Last Reply

Top Posters In This Topic

Pieliku listē. Bet no otras puses, šis liekas itkā hardkodētu immutējamus konfigurācijas objektus, kas neliekas pareizi. Bet vai tam vispār ir nozīme?

Parasti to liek config failā, kas developmentam ir savs, production savs. Neredzu nekādu hard codēšanas problēmu.

 

Ja objektu izmanto, kā konfig, tad masīvus var definēt metodēs (ja nav PHP5.6).

 

 

Vēl var izmantot

  • config.php - vispārējā konfigurācija - dev/test/prod kopīga
  • config-local. php - specifiska instalācijai

Vēl var skaldīt:

  • config_www.php
  • config_console.php
  • config_fronted.php
  • config_backend.php
Edited by l27
Link to comment
Share on other sites

Pieliku listē. Bet no otras puses, šis liekas itkā hardkodētu immutējamus konfigurācijas objektus, kas neliekas pareizi. Bet vai tam vispār ir nozīme?

Hardkodēd nedrīkst programmas tekstā. Config fails ir izņēmums. Nesaprotu par ko satraukums, ka kaut kas hardcodēts?

Galvenais, lai kodā ir ērti izmantots un saprotams un konfigurācija ir vienā vai dažos failos.

Edited by l27
Link to comment
Share on other sites

Es runāju par kaut ko citu. Ilustrēju problēmu:

 

<?php
namespace Config
{
    // Prod
    class ConfigFooBar()
    {
        const x = 1;
    }
    // Dev, citā failā, obviously
    class ConfigFooBar()
    {
        const x = 2;
    }
}
namespace Blah
{
use Config;
    class MyClass
    {
        $x = ConfigFooBar::x; // Nemutējama statiska reference
        // Autoloader eksplodē liesmās
    }
}
Kuru no ConfigFoobar ielādēs PSR? To, kurš ir attiecīgajā namespace failā. Lai to novērstu ir jāveido divi faili, katrs savā namespace/direktorijā.

 

Tad vēl ir sintakse $foobar::x, un tad varētu typehintot, bet tas nemaina faktu, ka nepieciešams papildus autoload un pieeja pēc name piedrazo scope ar daudz mainīgajiem. Šī pieeja nav īsti ne ar ko labāka par imutējamu konfig konteineri kā servisu vai di.

 

P.S. Es tagad iedomājos arī par spec/unit testiem. Well...

Edited by F3llony
Link to comment
Share on other sites

Es runāju par kaut ko citu. Ilustrēju problēmu:

 

Kuru no ConfigFoobar ielādēs PSR? To, kurš ir attiecīgajā namespace failā. Lai to novērstu ir jāveido divi faili, katrs savā namespace/direktorijā.

 

Tad vēl ir sintakse $foobar::x, un tad varētu typehintot, bet tas nemaina faktu, ka nepieciešams papildus autoload un pieeja pēc name piedrazo scope ar daudz mainīgajiem. Šī pieeja nav īsti ne ar ko labāka par imutējamu konfig konteineri kā servisu vai di.

 

P.S. Es tagad iedomājos arī par spec/unit testiem. Well...

 

 

Parasti uz DEV sistēmas config failā ir vieni setingi, uz testa citi un productiona citi. Nekad dev konfig failā nekrāmē production konfig. Sevišķi MySql connection details nevienam nav jāredz.

 

Ja būs viena config klase, nu nebūs konflikti.

Link to comment
Share on other sites

Uztaisa abstraktu konfigurācijas interfeisu, kuru izmanto neatkarīgi no tā, kā glabājas konfigurācija.

Uztaisa konfigurācijas ielādētāju katram atsevišķam, nepieciešamajam gadījumam (yaml, php, json, utt.).

Ja ielādēšana katrreiz par lēnu, konfigurāciju kešo.

Ja svarīgs kopējais ātrums nomainām PHP pret Scalu.

Link to comment
Share on other sites

Nez, parasti katram freimworkam ir savs standarta veids, kā glabāt. Visbiežāk jau tas ir masīvs. 

 

Es vispār nesaprotu, kur ir problēma. Kāpēc configi vispār jāšēro? Katrai sistēmai savs veids kā viņš glabājās. Ja ir custom sistēma, tad taču nenošērosi savu custom configu. Ja ir standarta freimworks, tad arī ir standarta configs.

 

Esmu cilvēks, kam patīk izmantot IDE, tāpēc ja rakstītu no 0, gan jau rakstītu klasē, lai suggestioni forši strādā.

Link to comment
Share on other sites

Uztaisa abstraktu konfigurācijas interfeisu, kuru izmanto neatkarīgi no tā, kā glabājas konfigurācija.

Tā (ne)darbosies validācija tikai 1 līmenī, konfigurācijas struktūra parasti ir vismaz 2 līmeņi. Interfeiss nekādā veidā nepalīdzēs enforsēt shēmu.

 

Uztaisa konfigurācijas ielādētāju katram atsevišķam, nepieciešamajam gadījumam (yaml, php, json, utt.).

 

Nav pat tādas vajadzības. Ja viens avots, tad viens avots.

 

Ja ielādēšana katrreiz par lēnu, konfigurāciju kešo.

 

Ja ielādēšana katru reizi ir par lēnu, konfigurāciju glabā PHP un izmanto opcache.

 

Ja svarīgs kopējais ātrums nomainām PHP pret Scalu.

 

Go home, troll. Scala is irrelevant and gay. 

 

 

@Briedis es tev pilnīgi piekrītu, taču problēma šeit tāda, ka atkal, single level. Ide tev nepateiks priekšā masīva saturu. Ja, piemēram, JS mēs varam pateikt ka 

{
    foo : {
        bar: []
    }
}

un IDE to pat atrisinās, tad PHP tādas konstrukcijas vēl diemžēl nav. 

Edited by F3llony
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...