Jak podchodzicie architektonicznie do pewnie często spotykanego problemu:
Zaprezentować (przykładowo w aplikacji ASP.NET MVC) widok tabeli w której w jakieś kolumnie mogą być zarówno stringi, inty, decimale. Tworzycie na backendzie List<object> i po niej foreachujecie na widoku czy jest jakieś lepsze rozwiązanie na przechowywanie takich danych?
Nigdy odkąd programuje nie spotkałem się z potrzebą trzymania różnych typów prostych w jednej kolekcji, i jest to raczej oznaka że coś robisz źle.
Przykładowo robiąc jakiś raport składający się z różnych pól(int,string itp). Zamiast robić klasę widokową ze wszystkimi osobnymi polami można zrobić List<object> co umożliwi trzymanie wszystkiego w 1 polu i jeżeli w przyszłości dojdą nowe pola nie będzie potrzeby zmiany modelu widokowego. Nie są to korzyści?
No dobra, będziesz sobie "foreachowal" po tej swojej kolekcji i jaki masz plan na rozróżnienie co jest co? Co jest np imieniem, co wiekiem a co numerem telefonu, albo imieniem złotej rybki?
"a_s_f"
Można wtedy taka liste rozszerzyć do przykładowo takiej postaci:
List<Pole>
class Pole
{
public string Name {get;set;}
public object Value {get;set;}
}
Jak podchodzicie architektonicznie do pewnie często spotykanego problemu:
Nie widze tutaj zadnego wyzwania na poziomie architektury.
Zaprezentować (przykładowo w aplikacji ASP.NET MVC) widok tabeli w której w jakieś kolumnie mogą być zarówno stringi, inty, decimale. Tworzycie na backendzie List<object> i po niej foreachujecie na widoku czy jest jakieś lepsze rozwiązanie na przechowywanie takich danych?
W takim przypadku- jesli chodzi o wyswieltanie informacji- nalezy to traktowac jako cos czego typ raczej nie ma znaczenia, a wiec wszystko wyswietlic jako stringi.
Teoretycznie wyświetlasz tekst w tej kolumnie, to nie można po prostu List<string> po co Ci object? skoro i tak wykonasz koniec końców ToString()? Potrzebujesz po coś ten typ?
Ale i tak popieram @a_s_f że coś jest nie tak, albo po prostu opisałeś to w taki sposób.