2016-12-27 2 views
0

Это более важный вопрос типа практики.Весна Autowiring, у меня есть только одна реализация, я должен автоуведовать? И если да, должен ли я автоувеличивать реализацию?

Я слышал десятки раз, что:

а), когда весной автоматическое связывание лучше практика autowire интерфейса «не» реализации.

и ..

б) Я также слышал, что если у вас есть только «один» реализация, то вы не должны быть действительно с помощью интерфейса.

Вот моя дилемма, у меня есть интерфейс «MyService» и одна реализация MyServiceImpl. Я использую @Autowiredz MyService in MyController` и в 'MyServiceTest'.

У меня нет необходимости в другой реализации.

Очевидно, что это нарушает правило b), но аутсорсинг реализации нарушит правило a).

Так что мой вопрос: что мне делать? Должен ли я просто отказаться от использования Spring вообще в этом случае и просто создать экземпляр «MyService», используя новое ключевое слово?

+1

Не используйте новое ключевое слово! Если вы используете новое ключевое слово, служба больше не используется в контексте весны. – Patrick

+0

Спасибо, так что было бы лучшей практикой в ​​этой ситуации? Чтобы полностью потерять интерфейс и просто выполнить аутсорсинг реализации? Или сохранить его так же, как и с автоподзаводом inteface (хотя у меня только одна реализация?). –

ответ

1

Вы должны Autwire интерфейс, потому что таким образом, когда вы хотите изменить реализацию позже, вам нужно будет добавить только @Qualifier выше и не изменять имена в коде. Это также лучше для тестирования, когда вы вводите ложную реализацию.

1

Практика - это код для интерфейса не реализации. Если вы всегда пытаетесь подключиться к интерфейсу, то ваш код намного более гибкий и слабо связан. Поэтому следует стремиться к практике варианта а).

Но есть счетчики для этого. Многие другие выдающиеся разработчики считают, что интерфейс не требуется, пока не будет реализовано несколько реализаций. В случае только одной реализации вы можете @Autowire класса напрямую. Это не будет конец света и не будет резко увеличивать или уменьшать производительность. Но, как я уже упоминал перед вариантом, а) код намного более гибкий и слабо связан, чем вариант b).

1

Я предлагаю использовать interface, потому что мне нравится иметь возможность создать еще одну реализацию, даже мне не нужна она на данный момент. Но приложения будут меняться в стадии разработки или позже. Существует еще один человек, которому необходимо другое требование .

Так что для меня это ясно, быть открытым для изменений в будущем.

1

Я предлагаю вам использовать interface, потому что в будущем, если кто-то хочет улучшить/реализовать, это будет полезно.

И есть нигде не указано, что строго запрещено нарушать правило b. Вы можете пойти только с правилом @Autowired на interface и @Component на реализации.

Для более info go with this answer

+0

У меня есть еще один вариант, я верю. В настоящий момент я использую moks (mockMvc) для тестирования моего контроллера. Вместо этого я мог бы создать реализацию MyServiceStub и ввести его в контроллер. –

+0

Любые мысли об этом решении? –

1

Там нет однозначного ответа. Если это имеет смысл, используйте интерфейс.Не будьте парнем, который использует интерфейсы для всего, потому что они «лучше». Это не особая концепция Spring.

Если это единственная реализация, которая вряд ли будет изменена и предназначена исключительно для вашего приложения, перейдите и пропустите интерфейс. Нет никакой реальной пользы от использования одного, если это единая, собственная реализация, которая никогда не покинет ваше приложение. Даже если он изменяется часто, если это отдельный класс, исключительный для приложения, если поведение (ожидаемые входы и выходы) не изменяется, вам по-прежнему не нужен интерфейс.

Если вы производитель и другие приложения, скорее всего, будете использовать свой код, используйте интерфейс. Это позволяет потреблять вашу библиотеку, где вы можете возиться с кодом по своему желанию, пока вы придерживаетесь интерфейса (это означает, что вы не изменяете поведение, а меняете реализацию).

Если вы используете интерфейс, Autowire интерфейс, а не реализацию.

Смежные вопросы