Il mio collega sta cercando di recuperare solo le proprietà necessarie come best practice per evitare carichi di lavoro non necessari sul lato del database come di seguito.
public async Task<IEnumerable<Product>> GetProducts(List<int> ids)
{
var items = await _context.Products.Where(u => ids.Contains(u.Id))
.Select(u => new { u.Id, u.Name, u.Published })
.ToListAsync();
return items.Select(u => new Product{ Id = u.Id, Name = u.Name,Published = u.Published });
}
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public bool Published { get; set; }
public string MetaTitle { get; set; }
public string MetaKeywords { get; set; }
public string Sku { get; set; }
public decimal Price { get; set; }
public decimal Cost { get; set; }
public DateTime CreatedAt { get; set; }
///...And other properties goes here
}
Come hai visto, ci sono solo 3 proprietà recuperate dal database nonostante il prodotto abbia molte proprietà.
L'IMO che recupera tutte le proprietà non ha realmente un carico di lavoro importante. Lo farei solo nel caso in cui ci sia un problema di prestazioni nella query. sono stato indicato che non è possibile sapere cosa è esattamente ritornato dal metodo senza leggere i dettagli di implementazione. Non solo, non è possibile utilizzare esattamente lo stesso nome del metodo quando è necessario un altro metodo che abbia esattamente lo stesso segno di metodo ma recuperi proprietà diverse. Ad esempio
public async Task<IEnumerable<Product>> GetProducts(List<int> ids)
{
//logic goes here
return items.Select(u => new Product{ Id = u.Id, Name = u.Name,Published = u.Published });
}
public async Task<IEnumerable<Product>> GetProducts(List<int> ids)
{
//logic goes here
return items.Select(u => new Product{ Id = u.Id, Name = u.Name,Cost = u.Cost, Sku = u.Sku });
}
Il codice non verrà compilato perché ci sono esattamente gli stessi 2 metodi e uno di loro dovrebbe differenziare il suo nome. Sono sicuro che è davvero difficile dare nomi significativi a questi casi.
I suoi argomenti stavano restituendo tipi specifici (DTO) avrebbero causato un sacco di tipi nel progetto.
In realtà molti tipi non sono solo un problema. Non è possibile utilizzare esattamente lo stesso nome del metodo ed è molto difficile dare nomi significativi per i tipi e i nomi dei metodi.
La mia soluzione a questo problema, non mettere questa logica in un metodo. Query in linea ovunque venga utilizzata. Già non esiste una riutilizzabilità della query e anche la query in realtà non contiene alcun tipo di logica che meriti di essere riutilizzata in altri luoghi. Ma secondo la sua idea, le query non dovrebbero essere eseguite al di fuori dei metodi di servizio, perché le rigide regole di stratificazione.
Qual è la tua idea su come restituire l'entità parzialmente riempita dal metodo? In secondo luogo, cosa succede se vogliamo recuperare solo le proprietà richieste, quindi qual è il modo migliore per farlo?
So che dirai di usare DTO ma cercherò di progettare tutto in questo modo rendendo tutto più difficile quindi a mio avviso dovrebbe essere usato solo nel caso di problemi correlati alle prestazioni, ma ancora in fase di allestimento di query risolvono tutti questi problemi ma alcuni le persone hanno regole di stratificazione rigorose senza ragioni pragmatiche.
Mi piacerebbe sentire le tue opinioni.