Проверка и в обслуживании расположенные на слое объекты или бизнес-объекты?
Использование «limit» и «top» не будет работать со всеми серверами SQL (например, с Oracle). Вы можете попробовать более сложный запрос в чистом SQL:
select mt1.id, mt1."name", mt1.score, mt1."date" from mytable mt1
where mt1.id=2
and mt1."date"= (select min(mt2."date") from mytable mt2 where mt2.id=2)
2 ответа
Я определенно нахожусь в лагере Роки Лхотка. Я считаю, что ваши бизнес-объекты должно быть очень легко «переносить» между приложениями и уровнями пользовательского интерфейса. Добавление дополнительного «уровня обслуживания», скорее всего, добавит зависимости с вашими объектами и, следовательно, сделает их менее «переносимыми».
Если вы правильно напишете структуру бизнес-объектов, ваши бизнес-объекты должны иметь возможность правильно обрабатывать проверку между различными бизнес-объекты. CSLA.NET делает это правильно, имея отношения родитель / потомок, а также концепцию проверки зависимых свойств.
Я не уверен, что вы это поняли.
Предложение Мартина Фаулера в PEAA - это сервисный уровень API между UI (или клиентами) и уровнями домена / данных . он покажет любую функциональность, которая может быть использована клиентом.
Если вы посмотрите на Модель домена ( Здесь )
Объектная модель домена, которая включает как поведение, так и данные.
] Уровень домена будет содержать эти объекты, которые будут иметь действия / проверку (поведение) и состояние (данные)
Эти объекты могут быть повторно использованы в других приложениях, это также будет зависеть от вашего дизайна. уровень домена не должен зависеть от уровня обслуживания
. Таким образом, учитывая, что объекты домена имеют поведение (включая проверку) и данные. Уровень сервиса - это то, что вы хотите, чтобы ваше приложение открывало (чтобы оно функционировало).