Сколько бизнес-логики объекты Значения должны содержать?
Проблема в том, что начальное значение вашего reduce обратного вызова является первым элементом в массиве values, а затем вы переходите к назначению этого элемента:
acc[currency]
? (acc[currency] = acc[currency] + cur[currency])
: (acc[currency] = cur[currency]);
Итак, первый элемент получает мутирует каждый раз, когда вызывается sumValues. Вместо этого укажите пустой объект в качестве начального значения для reduce:
sumValues = values => {
return values.reduce((acc, cur) => {
for (const currency in cur) {
acc[currency]
? (acc[currency] = acc[currency] + cur[currency])
: (acc[currency] = cur[currency]);
}
return acc;
}, {});
};
sumValues = values => {
return values.reduce((acc, cur) => {
for (const currency in cur) {
acc[currency] ?
(acc[currency] = acc[currency] + cur[currency]) :
(acc[currency] = cur[currency]);
}
return acc;
}, {});
};
totalExpense = expense => {
const values = [];
if (expense['_values']) {
values.push(expense['_values']);
}
const subExpenses = Object.keys(expense).filter(child => {
return child[0] !== '_';
});
if (subExpenses.length > 0) {
for (const subExpense of subExpenses) {
let subtotal = this.totalExpense(expense[subExpense]);
values.push(subtotal);
}
}
if (values.length) {
return this.sumValues(values);
} else {
throw Error('No values in this expense');
}
};
const entertainment = {
_values: {
USD: 23,
AUD: 5,
},
'food & drink': {
_values: {
AUD: 83,
},
'local bar': {
_values: {
AUD: 28,
USD: 2,
},
},
},
minigolf: {
_values: {
USD: 112,
},
},
};
console.log(totalExpense(entertainment));
console.log(totalExpense(entertainment['food & drink']));6 ответов
Необходимо лучше назвать их Объектами Передачи или Объектами передачи данных (DTO).
Ранее этот тот же j2ee шаблон назвали 'Объектом значения', но они изменили имя, потому что это было перепутано с этим
http://dddcommunity.org/discussion/messageboardarchive/ValueObjects.html
Для ответа на вопрос я только поместил бы минимальную логику в свой DTOs, логику, которая требуется по причинам дисплея.
Еще лучше, если бы мы говорим об основанном на базе данных веб-приложении, я пошел бы вне ядра j2ee шаблоны, и использование В спящем режиме или Персистентность Java API для создания модели предметной области, которая поддерживает ленивую загрузку отношений, и используйте это в представлении.
Посмотрите Открытое заседание в поле зрения.
Таким образом Вы не должны программировать ряд DTOs, и Вы имеете всю бизнес-логику в наличии для использования в представлениях/контроллерах и т.д.
Мое персональное предпочтение состоит в том, чтобы поместить всю бизнес-логику в саму модель предметной области, которая находится в "истинных" объектах области. Таким образом, когда Объекты Передачи данных создаются, они - главным образом просто (неизменное) представление состояния объектов области и следовательно не содержат бизнес-логики. Они могут содержать методы для клонирования и сравнения, хотя, но суть кода бизнес-логики остается в объектах области.
Это зависит.
ой, я просто выбалтывал клише?
Основной вопрос попросить разработку объекта: будет логика, управляющая данными объекта отличаться или то же, когда использовал/использовал другими объектами?
Если различные области призыва использования к другой логике, воплотите его. Если это - то же, неважно, куда объект перемещается в, поместите его вместе с классом.
Идея соединить данные и бизнес-логику состоит в том, чтобы способствовать инкапсуляции, и выставить как можно меньше внутреннего состояния другим объектам. Тем путем клиенты могут полагаться на интерфейс, а не на реализации. Посмотрите, "Говорят, не Спрашивайте" принцип и Закон Demeter. Инкапсуляция помогает понять, что данные состояний могут быть в, легче прочитать код, легче отделять классы и обычно легче к модульному тесту.
Воплощение бизнес-логики (обычно в классы "Сервиса" или "менеджера") делает вопросы как, "где эти данные используются?" и, "В каких состояниях это может быть?" намного более трудный ответить. Это - также процедурный образ мыслей, обернутый в объекте. Это может привести к анемичной модели предметной области.
Воплощение поведения не всегда плохо. Например, уровень служб мог бы организовать объекты области, но не беря на себя их управляющую состоянием ответственность. Или при больше всего выполнении чтений/записей к DB, которые отображаются приятно для ввода форм, возможно, Вам не нужна модель предметной области - или болезненное объектное/реляционное отображение наверху, оно влечет за собой - вообще.
Объекты передачи часто служат для отделения архитектурных слоев друг от друга (или от внешней системы) путем предоставления минимальной информации состояния потребности слоя вызова, не выставляя бизнес-логики.
Это может быть полезно, например, при подготовке информации к представлению: просто выскажите мнение информация, в которой оно нуждается, и ничто иное, так, чтобы оно могло сконцентрироваться о том, как отобразить информацию, а не что информация отобразиться. Например, К могло бы быть агрегирование нескольких источников данных.
Одно преимущество состоит в том, что Ваши представления и Ваши объекты области отделяются. Используя Ваши объекты области в JSPs может сделать Ваш домен тяжелее для рефакторинга и способствует неразборчивому использованию методов считывания и методов set (следовательно повреждающий инкапсуляцию).
Однако существуют также издержки, связанные с наличием большого количества Объектов Передачи и часто большого количества дублирования, также. Некоторые проекты, которыми я был подряд с TO's, которые в основном зеркально отражают другие объекты области (который я рассматриваю антишаблоном).
Какой сказанный Korros.
Объект значения: = Небольшой простой объект, как деньги или диапазон дат, равенство которого не основано на идентификационных данных.
DTO: = Объект, который несет данные между процессами для сокращения количества вызовов метода.
Это определения, предложенные Martin Fowler, и я хотел бы популяризировать их.
Я соглашаюсь с Panagiotis: открытое заседание в поле зрения шаблон намного лучше, чем использование DTOs. Помещенный иначе, я нашел, что приложение намного намного более просто, если Вы передаете трафик в своих объектах области (или некоторый составной объект этого) от Вашего слоя представления полностью вниз.
Тем не менее трудно осуществить, потому что необходимо будет сделать HttpSession совпадающим с единицей работы слоя персистентности. Тогда необходимо будет удостовериться, что все модификации базы данных (т.е. создают, обновления и удаляет), являются намеренными. Другими словами, Вы не хотите это иметь место, что слой представления имеет объект области, поле изменяется, и модификация сохраняется без кода приложения, намеренно сохраняющего изменение. Другая проблема, которая важна для контакта с, состоит в том, чтобы гарантировать, что транзакционная семантика является удовлетворительной. Обычно выборка и изменение одного объекта области произойдут в одном транзакционном контексте, и не трудно заставить Ваш уровень ORM потребовать новой транзакции. То, что , оспаривание, является вложенной транзакцией, где Вы хотите включать второй транзакционный контекст в первом открытом.
, Если Вы не возражаете заниматься расследованиями, как API не-Java решает эти проблемы, стоит посмотреть на Активную Запись направляющих, которая позволяет страницам сервера Ruby работать непосредственно с моделью предметной области и пересекать ее ассоциации.