Как вы будете делать сортировку, отбор по сериализованным полям? выдирать все записи, а потом заниматься вот таким перебором? Размещения этих полей в одной таблице или вынос в другую - оба способа хороши, потому что все это понимает орм, sql и не ухудшает производительность, а вот в этом случае орм вы выкидываете, выкидываете и бд, потому что она не работает с вашими сериализованными данными. Я не советовал использовать расщепление сущности только для удобства, потому что надо описывать связи, соблюдать целостность внешних ключей и так далее, но плюсов это особо никаких не дает, это микрооптимизация.
ViewModel - это абстракция Представления. View и ViewModel связаны с друг другом. Например, постраничная таблица данных. В представлении есть таблица, переключатель страниц, и набор строк текущей страницы. В Модели Представления есть соответственно свойство номера страницы и методы переключения страниц и массив строк текущей страницы. Также в модели представления содержится собственно модель таблицы или источник этой таблицы. Представление подписано на свойства модели представления, а модель представления, соответственно, при случае тоже оповещает представление если вдруг какое-то свойство в ней изменилось. При переключении страниц, вызываются соответсвующие методы Модели Представления, которые воздействуют на модель, что-то с ней делают, выдирают нужные куски из всей таблицы (Модели) ложат в массив строк текущей страницы и уже передают это в Представление.
tlbeta: Неверно показывает гугл по запросу погоды мое расположение - потому что у меня отключена геолокация, а провайдер йота, и гугл по айпишнику считает что я в тверком районе москвы. А все дело в том, что гугл собирает данные айпишников клиентов, вай фай сетей, данные геолокаций у пользователей где она включена, с мобильных устройств (когда используется жпс) и так далее, совмещает все эти данные и отпределяет ваше расположение.
