Сколько логики я должен поместить свои методы репозитория при использовании шаблона репозитория?
Вы не можете использовать Файл, так как этот файл не существует независимо в файловой системе. Вместо этого вам нужен getResourceAsStream (), например, так:
...
InputStream in = getClass().getResourceAsStream("/1.txt");
BufferedReader input = new BufferedReader(new InputStreamReader(in));
...
5 ответов
Определите, где вы хотите использовать метод Register, возможно, в классе UserServices. Вы можете делегировать создание объекта UserFactory. В методе CreateNewUser () установите значения по умолчанию для пользователя и коллекции групп. Затем вызовите UserRepository.Save (newUser) для сохранения данных.
// UserServices class
public void Register(User newUser)
{
// add custom registration stuff.
_userRepository.Save(newUser);
}
// Application code
User user = UserFactory.CreateNewUser();
_userServices.Register(user);
// UserFactory
public User CreateNewUser()
{
// all new user, group creation
}
Лично я сохраняю шаблон репозитория в качестве замены sprocs. Таким образом, в моем репозитории будут такие методы, как getById (int id) , save () , add (DomainObject obj) и т. Д.
На бизнес-уровне, У меня будет userManager.registerUser (строковое имя пользователя, / * параметры и т. Д. * /). Это создаст объект домена. Этот метод просто вызывает метод add () на уровне данных.
Короче говоря, бизнес-уровень - это бизнес-y, а уровень данных - это данные-y.
Какова ваша мотивация в первую очередь использовать шаблон репозитория? Обычно репозиторий - это абстракция логики сохранения объекта. Он извлекает элементы (обычно) из базы данных, а также обрабатывает обновления, вставки и удаления.
Если бы вы писали тест для проверки некоторой логики и не хотели попадать в базу данных, какие объекты вам пришлось бы имитировать? Обычно репозиторий.
В сценарии A) вы не можете протестировать новый пользователь, созданный с правильными данными по умолчанию, без прямого обращения к базе данных. Из-за этого я бы рекомендовал сохранить всю бизнес-логику вне репозиториев и использовать ваш второй дизайн
В вашем примере кода я бы назвал метод Register операцией службы. Как операция службы, она будет принадлежать службе или бизнес-компоненту, а не репозиторию. По словам Эванса (известного DDD), репозиторий представляет собой подобный коллекции интерфейс для сущностей, хранящихся в вашей базе данных. Общая идея заключается в том, что вы предоставляете базовый доступ к своим сущностям в стиле CRUD через репозиторий, чтобы абстрагировать остальную часть вашего кода от деталей доступа к данным более низкого уровня, таких как инструмент ORM.
Я вижу две потенциальные проблемы "неправильности" (поскольку вы на самом деле не указали, что, по вашему мнению, с ними было не так).
Если проблема связана с сохранением группы при регистрации пользователя метод или сохранение пользователя в методах группы, то вы должны разделить их на разные методы. (т.е. Register () вызовет RegisterGroup () или GetGroup ()
. Если проблема связана с сохранением вещей до того, как пользователь действительно будет готов к концептуальному сохранению вещей, то отслеживайте, что они хотели добавить, и подождите, пока не появится общее " save "вызывается перед помещением какой-либо информации в хранилище.