Raccolta di informazioni sull'indirizzo IP e sulla workstation; appartiene a una classe statale?

Question

Raccolta di informazioni sull'indirizzo IP e sulla workstation; appartiene a una classe statale?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

2

Sto scrivendo un'utilità impresa che raccoglie informazioni sulle eccezioni e scrive nel registro eventi di Windows, invia un'email, ecc. Questa classe di utilità verrà utilizzata da tutte le applicazioni della società: web, BizTalk , Servizi Windows, ecc.

Attualmente questa classe:

contiene lo stato assegnato ad esso tramite proprietà pubbliche
chiama i metodi .NET Framework per raccogliere informazioni sui dettagli di runtime. Sono incluse chiamate a varie proprietà e metodi da System.Environment , Reflection dettagli, ecc.

Questa implementazione ha il vantaggio di consentire a tutti quei chiamanti di non dover effettuare autonomamente le stesse chiamate. Ciò significa meno codice per il chiamante da dimenticare, rovinare, ecc.

Questa classe di stato (per favore qual è la frase che sto cercando [come DTO]?) sa come risolvere / determinare i dettagli del runtime (come l'indirizzo IP e il nome del computer su cui è in esecuzione)?

Mi sembra, a pensarci due volte, che sia pensato per essere una classe che dovrebbe contenere lo stato e non sapere come chiamare in .NET Framework per trovare informazioni.

var myEx = new AppProblem{MachineName="Riker"};

//Will get "Riker 10.0.0.1" from property MachineLongDesc
Console.WriteLine("full machine details: " + myEx.MachineLongDesc);

public class AppProblem
{
    public string MachineName{get;set;}
    public string MachineLongDesc{
        get{
            if(string.IsNullOrEmpty(this.MachineName)
            {
                this.MachineName = Environment.MachineName;
            }
            return this.MachineName + " " + GetCurrentIP();
        }
    }

    private string GetCurrentIP()
    {
        return System.Net.Dns.GetHostEntry(this.MachineName)
                     .AddressList.First().ToString();
    }
}

Questo codice è stato scritto a mano dalla memoria e presentato per semplicità, cercando di illustrare il concetto.

c# solid class-design

posta p.campbell 10.04.2014 - 05:32

fonte

4 risposte

Leggi altre domande sui tag c# solid class-design

Quali sono i vantaggi di sicurezza di Google Caja rispetto all'utilizzo dell'API web worker? [chiuso] Va bene convertire il set di dati da stored procedure a IEnumerable

score 1 · Answer 1

Secondo la mia opinione, la raccolta (cioè getIp) e l'elaborazione (ad esempio setEmail) devono essere gestiti in classi diverse

ip gethering appartiene a un servizio di log che ha conoscenza di runtime, ambiente, contesto, sessione ....
l'elaborazione delle informazioni di registro appartiene a una diversa classe di persistenza della registrazione che ha un'interfaccia simile a una scrittura a solo repository e utilizza un dto di registrazione o il metodo di salvataggio ha diversi parametri

Esempio

public class LoggingService {
    private ILoggingRepository repository;

    private string getIp() {...}

    public LoggingService(ILoggingRepository repository) {this.repository=repository;}

    public logError(Date date, String message, Exception ex) {
        this.repository.save(date, message, ex, getIp(), getLoggedInUser(), ....);
    }
}

repository.save può essere implementato come sendEmail o salvato nel database o createErrorTicket .....

score 0 · Answer 2

Stai creando un livello di astrazione tra codice che genera eccezioni e codice che riporta eccezioni. Mi sembra che l'interfaccia per l'astrazione di livello inferiore - quella del reporting - includa solo l'accettazione di oggetti che rappresentano eccezioni con metodi definiti per ottenere una rappresentazione leggibile dall'uomo.

In generale, le eccezioni dovrebbero includere qualsiasi contesto per il problema che non è disponibile per qualsiasi cosa lo gestisca, nient'altro. Se il gestore ha più contesto, può avvolgere l'eccezione con le informazioni aggiuntive e trasmetterlo o semplicemente registrarlo.

Quindi, nella tua situazione, l'utility di segnalazione degli errori può recuperare il contesto aggiuntivo di cui è a conoscenza - i dettagli di runtime del codice che ha generato l'eccezione - e includerlo nel suo output.

Se sei preoccupato di inserire la logica in ciò che ritieni debba essere conservato in un semplice DTO, aggiungi la logica come passaggio intermedio tra l'accettazione dell'oggetto eccezione - forse questo è il DTO - e la segnalazione.

score 0 · Answer 3

It seems to me on 2nd through that it's meant to be a class that should hold state, and not know how to call out to the .NET Framework to find info.

Spot on. Quello che hai è solo un contenitore di dati. Non ha bisogno di alcun metodo; non ci sono dettagli di implementazione da nascondere. Ci sono un sacco di cose che potresti scegliere di fare con quei dati e più modi di fare ognuna di queste cose; se usi metodi invece di funzioni statiche, la classe aumenterà quando aggiungerai ogni nuovo caso d'uso che trovi.

Per i punti bonus, rendilo immutabile e dagli valore semantico.

score 0 · Answer 4

Vorrei creare un oggetto modello / impresa / trasferimento dati / POCO (qualunque cosa tu voglia chiamare) classe che detiene i dati che hai recuperato. Creo quindi una classe che chiamerebbe le API appropriate per raccogliere i dati e restituire l'oggetto del modello popolato che deve essere utilizzato dal rapporto / salvato nel mezzo di persistenza.

Al momento sto lavorando a un progetto piuttosto ampio che raccoglie i dati di configurazione del server Windows. Ho creato varie classi di repository per raccogliere i dati dai server utilizzando WMI / registry etc che popola un oggetto modello in base all'area di interesse. Ad esempio, ho un repository che raccoglie i dati dei servizi che popolano e restituiscono un modello ServicesData , un altro raccoglie i dati delle carte di rete, popolando un modello NicData ...