HoBTIDГуру дизайна и совершенство архитектурной мысли постепенно переписывает плохие участки.
А не продолжает говнокодить в том же стиле, как изначально была написана система.
Ключевое слово "постепенно".

HoBTIDПоскольку матрица это всего лишь ViewModel, она ничего не затрагивает из бизнес-логики.
На нее легко можно перевести отдельные списки, не трогая "половину приложения".
Да, понятно, что ViewModel. Только не понятно нафига оно. ViewModel в этом случае исключительно односторонняя. Хотя ViewModel по задумке обеспечивает связь в обе стороны. Кроме этого ViewModel концепия удобна в случае внятных инструментов биндинга. Для чего она нужна, если биндинга нет - не понятно.
Ну и вы нам так и не расказали свою сокровенную тайну как именно Model мапиться на ViewModel.

HoBTIDДа вы оказывается кое-что понимаете.

Снова нарываетесь на грубость.

HoBTIDЭто действительно тайна.
В колонке ViewModel указывается путь по свойствам до нужного реквизита, например:



Чем это принципиально лучше type safe switch case? В коротм не нужны константы на каждое свойство.

HoBTIDЗатем, по пути свойств определяются имена таблиц и колонок в БД. Строится запрос с JOIN'ами и из результата его выполнения заполняется матрица.

Ну, понятно. View слой самым прямым образом влияет на доступ к данным. И теперь вы полностью подтвердили мои догадки про джуниорство. Лет 7-8 назад я дизайнил решения именно таким же образом. "Универсально", но при этом то что называется термином Over Abstracted. "Универсальность" заключается в том что, действительно один и тот же код покрывает все сущности. Это с точки зрения молодого программиста мега опупенно. Но при этом на лицо все недостатки излишней абстрагированости:
- если появляются требования не задуманые изначально абстракцией, то нужно рефакторить саму абстракцию
- ООП идет лесом, так как нет никакой возможности заточить разное поведение, под разные сущности.
У меня, например, в проекте есть у бизнес сущностей сложное вычислимое свойство. Которое не только влияет на бизнес-процесс, но и требует специального отображения на view. И как же прикажете быть в таком Anemic View, где бизнес сущности принципиально отствутствуют? Выносить вычисления в БД? И подрезать таким образом переносимость?

MonochromatiqueНо как-то хотелось думать (не приведи Бог столкнуться), что в JAVA есть эквивалент - persons.OrderBy(p=>p.name)

Ещё пара месяцев и будет
personList.sort((p1, p2) -> p1.name.compareTo(p2.name));

OrderBy, тоже можно забабахать со ссылкой на getter.
http://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html

Только в данном случае в этом пользы особой нет.

maytonС++ возвращается?


Угу. Java и так не дружелюбна к нубам. А теперь со стрелочками и двоеточиями будет ещё головоломнее.

mayton



Я за то чтобы такой код не писать. Я за читаемость:

if(someObj.greaterThan(anotherObject)){
if(someObj.olderThan(anotherObject)){
if(greater(someObject, thenObject)){

И в том же духе. Имя метода должно следовать предметной модели.