Использование шаблона репозитория, лучше сохранить родительские и дочерние объекты вместе или отдельно?
Как именно вы можете изменить рабочий каталог bash (или parent в целом)?
Это не невозможно при использовании любой "приемлемый" способ. Под приемлемым я подразумеваю «без чрезмерного взлома вашей системы (например, используя gdb )»;)
Более серьезно, когда пользователь запускает исполняемый файл, дочерний процесс запускается в его собственная среда, которая в большинстве своем является копией своей родительской среды. Эта среда содержит «переменные среды», а также «текущий рабочий каталог», просто чтобы назвать эти две.
Конечно, процесс может изменить свою собственную среду. Например, чтобы изменить его рабочий каталог (например, когда вы cd xxx в вашей оболочке). Но поскольку эта среда является копией , это никак не меняет среду родителя. И нет никакого стандартного способа изменить вашу родительскую среду.
В качестве примечания, именно поэтому
cd ("chdir") является внутренней командой оболочки , а не внешней утилитой . Если бы это было так, он не смог бы изменить рабочий каталог оболочки. 4 ответа
Репозиторий должен обрабатывать весь агрегированный объект (родительский и все дочерние), потому что именно это делает его репозиторием. Если вы сохраняете корневой и дочерний объекты отдельно, то используемый вами шаблон на самом деле не называется репозиторием (хотя он все равно может быть отличным решением)
«Репозиторий» - это просто удобное имя для конкретного шаблон доступа к данным, который загружает и сохраняет целые агрегаты за один раз - поэтому, когда вы говорите другому разработчику, что вы используете шаблон репозитория, он знает, что происходит.
Я бы попытался использовать шаблон «Единица работы», в котором вы открываете, вносите изменения, фиксируете, а затем он просто определяет, что нужно делать.
Если вы в игре. реляционная база данных, вы получите что-то вроде Hibernate с сопоставителем для каждой таблицы. Если вы работаете с нереляционной базой данных, вам, возможно, придется проявить изобретательность и пометить объекты домена как IAggregateRoot или что-то в этом роде, чтобы знать, какие из них имеют свои собственные репозитории, а какие нет.
Например, если сотрудники хранятся в одной SOA и Адреса в другой каждый из них будет IAggregateRoots, и в идеале Unit of Work будет автоматически передавать каждый из грязных экземпляров в соответствующий репозиторий для сохранения.
Таким образом, это прозрачно для клиентского кода, но не бесполезный слой косвенного обращения (как правило, службы, в любом случае в мире Java - не всегда, но те, что я видел).
Мне нравится DDD, но я думаю, что он слишком сильно преувеличивает репозитории и, эмпирически, вызывает большую путаницу, потому что люди всегда спрашивают, как чтобы делать их правильно.
Если бы у меня не было системы с известными множественными бэкэндами на основе SOA (а не просто «эй, мы можем когда-нибудь стать Amazon и нуждаться в этом»), я бы лично избегал репозиториев. Картографы на основе Hibernate / DAO / что-то, конечно, но они кажутся более простыми и конкретными, чем репозитории.
Я предпочитаю репозиторий для каждой таблицы, но склеить их вместе в общий репозиторий:
public RootEmployeeRepository (
IEmployeeRepository employeeRepository,
IAddressRepository addressRepository)
{
// init
}
public SaveEmployee (Employee employee)
{
// call IEmployeeRepository to save the employee record minus childen
// call IAddressRepository to save employee.addresses
// commit all changes to the DB via UnitOfWork
}
Я предпочитаю NHibernate, который выполняет за вас каскадные сохранения.