Questo codice / logica dovrebbe essere incluso nella classe Business Objects o in una classe separata?

3

Ho creato una piccola applicazione che ha un'architettura a tre livelli e ho classi di oggetti business per rappresentare entità come User , Orders , UserType ecc. In queste classi ho metodi che vengono eseguiti quando il Viene chiamato il metodo Constuctor di, ad esempio, User. Questi metodi eseguono calcoli e generano dettagli che configurano i dati per gli attributi che fanno parte di ciascun oggetto User.

Ecco la struttura del progetto in Visual Studio:

Ecco un codice dalla classe dell'oggetto business User.cs:

Public Class User
{
    public string Name { get; set; }
    public int RandomNumber { get; set; }
    etc

        public User
        {
            Name = GetName();
            RandomNumber = GetRandomNumber();
        }

        public string GetName()
        { 
          ....
          return name;
        }

        public int GetRandomNumber()
        {
           ...
           return randomNumber;
        }

    }

Questa logica dovrebbe essere inclusa nelle classi Business Object o dovrebbe essere inclusa in una classe di utilità di qualche tipo? O nelle regole aziendali?

    
posta Theomax 03.07.2012 - 13:43
fonte

2 risposte

9

La teoria:
Una classe dovrebbe essere responsabile dei suoi dati e sapere cosa fare con i suoi dati. Qualsiasi metodo che la classe ha bisogno di applicare questa responsabilità dovrebbe rientrare nella classe.

In pratica:
Quindi la classe avrà User.Name e dovrebbe anche avere User.GetName(), User.GetFirstName(), User.GetLastName() come Nome appartiene all'Utente e l'Utente dovrebbe sapere come manipolare la sua proprietà Name.
Ad esempio, non ha un UserUtils.GetFirstNameFromName() .

Diciamo anche che abbiamo User.TaxID e ci dovrebbero essere istruzioni get / set appropriate per recuperare quella proprietà. Tuttavia, dovremmo non avere User.CreateTaxID in quanto la classe User non dovrebbe / non dovrebbe avere nulla a che fare con il recupero di un identificatore esterno nella classe.
Invece, questo è un ottimo caso per UserUtils.CreateTaxID .

Quindi la risposta alla tua domanda è sia "sì" che "no" a seconda di ciò che le funzioni stanno effettivamente facendo.

    
risposta data 03.07.2012 - 14:08
fonte
0

Se vuoi seguire i principi OO, la risposta a questa domanda è sì. Un oggetto è responsabile della gestione del suo stato e comportamento. Ciò significa che tutte le proprietà e i metodi che descrivono l'oggetto dovrebbero essere implementati nella classe base.

Questa è una regola scritta, una teoria.

Dai il lato pratico, puoi decidere di dividere le classi per molte ragioni:

  • Organizzazione personale
  • La leggibilità
  • Evita classi enormi

Questo dipende da te.

    
risposta data 03.07.2012 - 14:44
fonte

Leggi altre domande sui tag