Ho strutturato i miei livelli di "servizio" (o, quello che pensavo fosse una funzionalità simile al servizio) come classi statiche in cui ogni classe è un raggruppamento di funzioni complementari che insieme forniscono un insieme coerente di operazioni per supportare i bisogni dei livelli di consumo .
public static class ElementService
{
public static Element GetElementByAtomicNumber(int atomic_number)
{
ElementRepositorySQL elementRepositorySql = new ElementRepositorySQL();
return elementRepositorySql.Read(atomic_number);
}
}
Ad esempio, i controllori usano il livello di servizio per leggere / scrivere su un repository invece di gestirlo direttamente.
public class ElementController
{
public ElementModel Model {get; set;}
public void LoadModel(int atomic_number)
{
Model = new ElementModel();
Element e = ElementService.GetElementByAtomicNumber(atomic_number);
Model.Name = e.Name.ToUpper();
Model.Weight = Math.Round(e.AtomicWeight,4).ToString();
}
}
10 Golden Rules Of Good OOP , la regola # 5 afferma:
- Avoid Static Classes for Helpers, Utilities & C
Unfortunately, static classes act frequently as a global state and create the non-determinism that should be avoided. But it gets worse. Since static classes can be used everywhere in the code without being passed explicitly as parameters, they create secret dependencies that are not revealed by the API documentation.
Non vedo come questo sarebbe un grosso problema se le chiamate al servizio sono fatte rigorosamente all'interno del livello per cui sono state progettate? Ho una convenzione in cui solo i controller chiamano il servizio strato; quel particolare insieme di servizi supporta i controller.
Last, but not least, code using static classes is not testable in isolation, making unit testing a nightmare.
Unless strictly needed for performance reasons, the use of static classes should be avoided. Static variables are still OK for constant objects (although a static property without setter would be better) or to hold private references to objects inside factory classes.
La maggior parte delle funzionalità fornite da questi servizi è così semplice che credo che il testing delle unità sarebbe semplicemente eccessivo (record di lettura / scrittura di id).
Considerando queste circostanze, varrebbe ancora la pena di refactoring dell'implementazione della classe statica? È una buona porzione di codice, quindi avrei bisogno di un RoI comparabile.