Есть ли приемлемый способ разделить эти слои / зависимости? - PullRequest
0 голосов
/ 18 ноября 2010

В настоящее время я борюсь с тем, достиг ли я хорошего уровня разделения, или я где-то упустил момент, поскольку я относительно новичок в изучении дисциплинированной стороны развития ...

Моя цель, когда я начинал, состояла в том, чтобы создать слой, независимый от любого механизма персистентности - я назвал это data-api. Затем я реализовал эти интерфейсы с помощью JDO и назвал этот проект data-jdo. Логический уровень в идеале говорит только в курсе data-api.

Это тот момент, когда я не уверен, что имеет смысл. Слой бизнес-логики должен вызываться как-то, верно? Так есть ли ожидание, что реализация data-api (data-jdo или что-то еще, в зависимости от экспериментов) обеспечивается (уместно сказать / делать инъекцией?) Инициатором?

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

Должен ли я использовать какой-то фреймворк, такой как Spring, чтобы позволить мне выбирать, какая реализация моего data-api используется через XML?

Извините, если это немного расплывчато ... Я предполагаю, что основной вопрос в том, в какой момент потребитель API зависит, поставляет или связывается с реализацией этого API? Если ответом является или должно быть «никогда», то что используется для того, чтобы убедиться, что все доступно во время выполнения, и как потребитель получает экземпляр того, что «API» описывает только с интерфейсами?

Ответы [ 2 ]

1 голос
/ 18 ноября 2010

Ваш data-api - это интерфейсный уровень DAO, это все, что ваш бизнес (или сервисный уровень) должен знать о постоянстве.А уровень представления или любой другой уровень выше бизнес-уровня не должен иметь каких-либо «знаний» о нижележащем уровне DAO.

Чтобы достичь этого, полагаться на такую ​​среду, как Spring, - хорошая идея.Уровень верхнего уровня загружает контекст приложения, который содержит всю информацию для платформы, чтобы загрузить соответствующую реализацию.

Например, вы можете загрузить applicationContext.xml из внешнего интерфейса, чтобы использовать data-jdo, и загрузить testApplicationContext.xml из модульных тестов, чтобы использовать data-jpa.

1 голос
/ 18 ноября 2010

Я пришел из .net, а не из Java, поэтому боюсь, что не могу помочь вам с особенностями Java.

Уровень бизнес-логики должен бытьвызывается как-то, верно?Так есть ли ожидание, что реализация data-api (data-jdo или что-то еще, в зависимости от экспериментов) обеспечивается (уместно сказать / делать инъекцией?) Инициатором?

Да.В мире .Net я использую Factory (как в случае Factory Pattern ), который динамически возвращает реализацию провайдера данных (какой из них использовать устанавливается в config).Поставщик данных возвращается фабрикой как «объект», и от вызывающего кода бизнес-логики зависит, приведёт ли он его к правильному типу - в зависимости от интерфейса, с которым работает бизнес-логика.

I'v egot (еще одна!) статья о Внедрение зависимостей для .Net, которая может помочь объяснить некоторые проблемы, но я уверен, что где-то есть хорошие java-приложения.

Должен ли я использовать какой-то фреймворк, например Spring, чтобы позволить мне выбирать, какая реализация моего data-api используется через XML?

Возможно.Я бы сказал, что сначала вы потратите время, чтобы разобраться с концепциями, а потом позаботьтесь о «лучшей практике».К вашему сведению, я выучил AJAX трудным путем - написав весь код самостоятельно.В эти дни я бегал прямо к хорошей структуре, но я только думаю, что у меня есть уверенность, чтобы сделать это после того, как действительно ухватился за основы, сделав некоторую жесткую прививку на угольном забое :))

... Если ответ будет или должен быть "никогда", то что ...

Да - это никогда .Используйте Фабрику.

...