Из моего понимания уровня обслуживания я не знаю, как вы это сгенерируете; если написано правильно, оно должно быть в значительной степени основано на вашей бизнес-модели и вообще не должно следовать схеме вашей базы данных. В отличие от DAO (возможно, у меня на самом деле тоже нет однозначного объекта DAO), у вас не должно быть службы для каждого объекта, вместо этого ваши службы должны использовать объекты как часть своего API для выполнения единиц измерения. работать или предоставлять бизнес-объекты, являющиеся уровнем абстракции между управляющей логикой и доступом к данным. Это также может быть гибридом обоих. Это зависит от сложности приложения и от того, насколько тесно ваши DAO / сущности связаны с вашей базой данных.
РЕДАКТИРОВАТЬ: Исходя из вашего комментария и большой спешки, я бы использовал инструменты, упомянутые в других публикациях, для создания слоя DAO, который даст вам очень хорошее начало. Затем я бы создал один объект Service, который содержит все ваши DAO. Оттуда у вас будет доступ ко всей вашей бизнес-логике в тестируемом контейнере (объект службы). Это не позволит вам поместить его в контроллеры и даст единственное место, где люди смогут увидеть все методы бизнес-логики. По мере роста вы увидите избыточность и логические единицы, которые вы позже могли бы разделить на разные сервисные объекты.
Надеюсь, у вас будет время для этого, но когда я в спешке, мне нравится, когда вся моя сложность в бизнесе связана с одним сервисным объектом, а не со многими контроллерами. Рефакторинг, который вы сделаете позже, будет намного проще. И вы все еще можете легко тестировать методы, которые я бы порекомендовал, независимо от спешки, поверьте мне, быстрее писать тесты для сервисных методов, чем тестировать их путем развертывания и проверки.