WPF háttér cs-ben egy függvény public vagy internal
2015-02-21T22:29:13+01:00
2015-02-23T15:02:17+01:00
2022-08-09T10:41:52+02:00
iolah2
Sziasztok
C# Wpf .cs háttérfájlában írtam hivatkozást egy még meg nem írt függvényre(vagy methodus), majd ctrl+pont-al lekreáltam.
Ekkor internal fv-t generált.
Most akkor public, vagy internál függvényt érdemes használni egy kis alkalmazáson belül?
Olvasgattam, de nem látom mi szól az egyik, vagy a másik mellett.
Köszönöm

pl: public void Refresh(){...}, vagy internal void Refresh(){...}
Mutasd a teljes hozzászólást!
mikor használunk egyáltalán külső assemly-ket.

Erre nincsenek kőbe vésett szabályok. Tipikusan a következő okok miatt célszerű külső assembly-ket használni (saját kútfőből, így a lista nyilván nem teljes):

- funkciók elkülönítése, alkalmazás rétegezése esetén, azaz pl. külön assembly foglalkozik az adatbázis-kezeléssel, üzleti logikával, megjelenítéssel stb.
- közös, újrafelhasználható komponensek használata esetén (tipikus példa: user control-ok)
- hirtelen nem is tudok többet írni, a fenti kettő lefed mindent, ami most eszembe jut

Ide tartozik még, hogy csak akkor fordul újra egy assembly, ha változtatsz valamin, így nagy alkalmazás esetén jelentősen nőhet a fordítási, indulási idő, hiszen nem a teljes alkalmazás fordul mindig feltétlenül újra (pl. ha az UI-t változtatod).

két WPF xaml.cs "háttérosztály" és az egyiket példányosítva szeretném a másikból meghívni.

Ez már eleve rossz ötletnek hangzik, persze nem láttam a konkrét kódodat. De két UI kódnak nem kéne egymásra hivatkoznia (legalábbis nem explicit módon a code-behind-ban).

Sőt, WPF esetén eleve más elvek mentén kéne programokat írni, mint Forms esetén, így sokszor a code behind üres maradhat. Ld. a témában Dante kolléga WPF bevezetőjét. Ez így persze együtt már lehet, hogy túl sok lesz, de mindenképpen fontosnak tartottam megjegyezni.

Ehhez kell hogy lássam, ahogy látom az internal-lal is látja, de kell-e, vagy milyen esetben kellene a public?

Akkor kéne public, ha pl. egy user control-t készítesz pl. egy WPF User Control Library projectben (külső assembly), és a fő alkalmazásodban arra hivatkozol. Ilyen esetben ha internal-t használsz, akkor a fő alkalmazás (.exe) nem fogja látni.

Szerk.: ha maguk az OOP-elvek is újak még, akkor nem WPF-fel kéne kezdeni, akármennyire is kevésbé látványos egy konzol alkalmazás. Tutorialból elég sok elérhető, javaslom rögtön a Microsoft saját előadássorozatát.
Mutasd a teljes hozzászólást!

  • Helló!

    Ez az OOP-alapokhoz vezet: mire jó az egyik és mire jó a másik? Ld. Access Modifiers.

    Public: külső assemblyből is látható az adott metódus.

    Internal: csak az adott assembly-n belül látható az adott metódus.

    Code behind-ban egyébként az encapsulation jegyében sokszor inkább private (vagy protected) ajánlott.
    Mutasd a teljes hozzászólást!
  • Szia!

    Igen neten pont ezt találtam, de ebből számomra nem világos, mikor használunk egyáltalán külső assemly-ket.



    Amúgy nekem csak annyi lenne a lényeg, hogy van két osztályom, pontosabban két WPF xaml.cs "háttérosztály" és az egyiket példányosítva szeretném a másikból meghívni.
    Ehhez kell hogy lássam, ahogy látom az internal-lal is látja, de kell-e, vagy milyen esetben kellene a public?

    private/protected módon ezt nem érném el, legalábbis ha jól értem a protected csak származtatott osztályra van
    Mutasd a teljes hozzászólást!
  • Ha DLL-t írsz, akkor inkább public, kis projekt esetében elég az internal. Ha Solution-on belül maradsz, akkor is jó az internal. Gyakorlatilag azonban teljesen mindegy, mióta létezik a .NET Reflector. Én mindenhol public-ot használok, ahova elég lenne az internal, igazából nem kell nagy feneket keríteni a dolognak.
    Mutasd a teljes hozzászólást!
  • mikor használunk egyáltalán külső assemly-ket.

    Erre nincsenek kőbe vésett szabályok. Tipikusan a következő okok miatt célszerű külső assembly-ket használni (saját kútfőből, így a lista nyilván nem teljes):

    - funkciók elkülönítése, alkalmazás rétegezése esetén, azaz pl. külön assembly foglalkozik az adatbázis-kezeléssel, üzleti logikával, megjelenítéssel stb.
    - közös, újrafelhasználható komponensek használata esetén (tipikus példa: user control-ok)
    - hirtelen nem is tudok többet írni, a fenti kettő lefed mindent, ami most eszembe jut

    Ide tartozik még, hogy csak akkor fordul újra egy assembly, ha változtatsz valamin, így nagy alkalmazás esetén jelentősen nőhet a fordítási, indulási idő, hiszen nem a teljes alkalmazás fordul mindig feltétlenül újra (pl. ha az UI-t változtatod).

    két WPF xaml.cs "háttérosztály" és az egyiket példányosítva szeretném a másikból meghívni.

    Ez már eleve rossz ötletnek hangzik, persze nem láttam a konkrét kódodat. De két UI kódnak nem kéne egymásra hivatkoznia (legalábbis nem explicit módon a code-behind-ban).

    Sőt, WPF esetén eleve más elvek mentén kéne programokat írni, mint Forms esetén, így sokszor a code behind üres maradhat. Ld. a témában Dante kolléga WPF bevezetőjét. Ez így persze együtt már lehet, hogy túl sok lesz, de mindenképpen fontosnak tartottam megjegyezni.

    Ehhez kell hogy lássam, ahogy látom az internal-lal is látja, de kell-e, vagy milyen esetben kellene a public?

    Akkor kéne public, ha pl. egy user control-t készítesz pl. egy WPF User Control Library projectben (külső assembly), és a fő alkalmazásodban arra hivatkozol. Ilyen esetben ha internal-t használsz, akkor a fő alkalmazás (.exe) nem fogja látni.

    Szerk.: ha maguk az OOP-elvek is újak még, akkor nem WPF-fel kéne kezdeni, akármennyire is kevésbé látványos egy konzol alkalmazás. Tutorialból elég sok elérhető, javaslom rögtön a Microsoft saját előadássorozatát.
    Mutasd a teljes hozzászólást!
  • Szia
    Kicsit helytelenül fogalmaztam, valójában a példányosított egy UserControl
    Van egy Foablak.xaml.cs-öm, ahol komunikálok a UC1 és UC2 usercontrols között

    public void TermelesFrissites(Termelés termelesM, int reszTetelAZM) { focusModVon(true, true);// UpdateLayout(); VonUC2.Refresh(termelesM, reszTetelAZM); //munkalapM, VonUC2.elkeszult.Focus(); UpdateLayout(); VonUC2.elkeszult.SelectAll(); //von2tab.Visibility = Visibility.Visible; }
    Ezt a UC1-ből hívom meg, és tervem, hogy frissítve megnyissa a UC2-öt. Mindkettő a Foablak.xaml-ben van egy tabcontrol-on példányosítva

    <TabControl x:Name="tabs" Grid.Column="2" Margin="0 0"> <TabItem x:Name="von1tab"> <TabItem.Header> <TextBlock Text="Vonalkód" TextAlignment="Center" Width="329" FontSize="30" Padding="5,2"/> </TabItem.Header> <uc:VonalkodUc1 x:Name="VonUC1" Loaded="VonUC1_Loaded" /> </TabItem> <TabItem x:Name="von2tab" Visibility="Collapsed"> <TabItem.Header> <TextBlock Text="Vonalkód" TextAlignment="Center" Width="329" FontSize="30" Padding="5,2"/> </TabItem.Header> <uc:VonalkodUc2 x:Name="VonUC2" Loaded="VonUC2_Loaded" /> </TabItem></TabControl>


    Igazából nem használtam külön assembly-t a usercontrol-okhoz, egy projektben, külön mappába tettem őket. De ha nem fontos, nyugodtan maradok a public használatánál
    Mutasd a teljes hozzászólást!
abcd