Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, snaphold, Вы писали: S>>специфические поля есть у студента или пенсионера которые участвуют в валидации этих сущностей или которые потом кладутся в отд таблицы. S>>изначально если что был одинй широкий класс. но писать кучу ифов надоело S>Пихать логику в entity-классы — плохая идея, есличо.
entity классы не содержат логику.
в классе модели логика
цепочка такая: файл — парсится в массив класса модели — валидация — создание сущностей энтити и вставка в таблицы
Сериализация уже выдумана, и поддреживает списки обьектов с общим предком но разным типом.
Если используется самопальная схема- придется реализовать регистрацию типов обьектов по id, и генерацию их при десериализации с помощью рефлексии или самопального метода из списка зарегистрированных типов
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vaa, Вы писали: vaa>>сущность не должна обладать поведением? S>Ага. Анемик-дизайн.
тогда это не сущность а запись. если придираться к терминам.
именно запись в БД. как во времена dbf foxpro.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, snaphold, Вы писали:
S>>специфические поля есть у студента или пенсионера которые участвуют в валидации этих сущностей или которые потом кладутся в отд таблицы. S>>изначально если что был одинй широкий класс. но писать кучу ифов надоело
НС>Не пиши кучу ifов, используй switch. НС>А на что ты хочешь их заменить в случае наследников? На виртуальные методы? Визитор?
паттерн Стратегия.
Есть СтратегияСтудент, СтратегияПенсионер и в каждом свое спец поведение.
то есть пока логика такая
пришел 1 файл с разными типами людей
универс метод парсинга вернул массив сущностей Персон
Далее разделили этот массив на массивы разных сущностей
Запустили валидацию и сохранение каждого массива в отдельной стратегии
Здравствуйте, snaphold, Вы писали:
S>пришел 1 файл с разными типами людей S>универс метод парсинга вернул массив сущностей Персон
по-моему у вас много лишних преобразований. сразу в момент парсинга создавать инстанс нужного класса.
во-первых надежней. особенно если поля персоны мутабельные.
во-вторых, меньше выделений памяти.
Здравствуйте, snaphold, Вы писали:
S>паттерн Стратегия. S>Есть СтратегияСтудент, СтратегияПенсионер и в каждом свое спец поведение. S>то есть пока логика такая
Эммм... А что если пенсионер решил поучиться и стал студентом? Не говоря уж про армейских пенсионеров и прочих категорий, имеющих возможность выйти не по возрасту, а по выслуге лет, льготе и т.п.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Эммм... А что если пенсионер решил поучиться и стал студентом? Не говоря уж про армейских пенсионеров и прочих категорий, имеющих возможность выйти не по возрасту, а по выслуге лет, льготе и т.п.
В соответствии с теорией: определить необходимые типы данных.
Когда точно известно с какими типами работаем, легко понять какие функции необходимы для обработки входных данных.
Здравствуйте, vaa, Вы писали:
vaa>В соответствии с теорией: определить необходимые типы данных. vaa>Когда точно известно с какими типами работаем, легко понять какие функции необходимы для обработки входных данных.
Ну вот в том-то и ситуация, что типы данных крайне нежелательно пронизывать бизнес-логикой. Переделывать — будет больно.
Не говоря уж про армейских пенсионеров и прочих категорий, имеющих возможность выйти не по возрасту, а по выслуге лет, льготе и т.п.
