Architettura: I valori di default del modulo sono considerati business logic e dove dovrebbe essere collocata la logica per calcolarli?

StartDate e EndDate di cosa? .... l'anno scolastico? Ok:

public class SchoolYear {
     StartDate = DateTime.Now;
     EndDate = new DateTime (2016, 6, 23);
}

La programmazione orientata agli oggetti riguarda, beh, gli oggetti: Metti le proprietà in una classe per descrivere / definire in modo appropriato di cosa si tratta. Scrivi metodi contro queste proprietà per descrivere / definire ciò che fa.

Come per "logica predefinita complessa". Nonostante "Complex" o "default", mettiamo la logica con le proprietà con cui va, quindi entrambe in una classe appropriata. Se per "complessità" si intende la necessità di interagire tra classi e oggetti diversi, OK, ma ogni classe / oggetto è responsabile della propria azione.

A School Year sicuramente non avrà il gruppo di insegnanti definito in esso, tuttavia un Teacher potrebbe avere il suo Calendar inizializzato con SchoolYear.StartDate .

Ho affermato che i valori predefiniti sono logici aziendali e dovrebbero essere testati come tali in una recente revisione del codice. Non è difficile estrarre la logica di inizializzazione in qualunque componente possieda la "presentazione" della propria vista. In sostanza, chiediti perché un valore predefinito dovrebbe essere trattato diversamente da un valore .. Non so ... "normale". Se ammetti che i valori predefiniti sono speciali, stai ignorando volontariamente la logica solo perché sembra essere banale.

In un'applicazione web di tipo MVC, i valori predefiniti inviati con una richiesta di modulo dovrebbero essere generalmente inseriti nella vista direttamente. Questo vuol dire che il controller non dovrebbe preoccuparsi di ciò che arriva, fintanto che i parametri sono validi (e, visto che queste cose vanno, è sempre una buona idea controllare l'input dell'utente).

Tuttavia, è anche vero che i valori predefiniti possono diventare complicati come hai detto. Dì che vuoi che la data di inizio predefinita sia quando è stato effettuato un ordine. Se questa fosse un'applicazione web, ovviamente non hai queste informazioni facilmente. Dovresti passare alla pagina in modo che la pagina possa usarla come valore predefinito.

In questo caso, direi che dovresti consentire la possibilità di non inviare una data di inizio. Il server, dopo aver visto che non è stata fornita una data di inizio, fornisce l'impostazione predefinita. Questi tipi di parametri, a differenza di quelli che sono costanti o che non dipendono dallo stato del modello, devono essere considerati business logic e dovrebbero avere i valori predefiniti presi dalla parte del modello dell'applicazione. Se fatto bene, l'utente non avrà molti parametri con i valori predefiniti, ma solo pochi parametri obbligatori con la possibilità di aggiungere parametri aggiuntivi. Questo rende la tua richiesta molto più organica e hai meno convalida di cui preoccuparti, rendendola anche più robusta. Inoltre, la tua vista diventerà più intuitiva da usare.

Questa è una domanda molto ampia ... Troppo ampia per rispondere davvero bene ...

Stiamo parlando di cose come i giorni della settimana? stiamo parlando di cose che contano solo per l'interfaccia utente e la Business Logic non interessa? stiamo parlando di valori che derivano dalla vera Business Logic?

1. Alcuni valori predefiniti provengono direttamente da Business Logic. Per esempio. impiegare rango, è un prodotto un frutto o un vegetale, metodo di pagamento preferito. di solito questi valori provengono da un set predefinito e possono cambiare con il tempo e i requisiti. Questi valori e i loro sordomuti dovrebbero probabilmente provenire da dati cioè una base dati. che li lascerà liberi di cambiare facilmente e l'interfaccia utente non gli interesserà. A volte questi valori hanno una logica più intelligente dietro di loro, ad esempio l'app "Waze" che ti offre di guidare a casa o di lavorare a seconda di dove ti trovi.

2. A volte i valori predefiniti sono rilevanti solo per l'interfaccia utente e l'usabilità dell'utente. Se ho un metodo come SearchSomething(Time start, Time end) nel BL (livello aziendale). Non mi importa meno dei valori che ottengo, e forse clienti diversi vorrebbero avere valori predefiniti diversi? Quindi è qualcosa che dovrebbe essere determinato nell'interfaccia utente, ma non vorrei sporcare una vista MVC con questo. Penso che sia più appropriato come parte di un modello.

3. Alcuni valori predefiniti sono così comuni e banali che non importa dove li metti. potresti ingenuamente inserirli nell'interfaccia utente, nella vista stessa o in una classe Constants nella BL. A seconda di cosa hai effettivamente bisogno ...