Предстои ми да приложа модел на DAO дизайн в моя проект и разбирам, че това най-често се използва за комуникация с базата данни.
Но тъй като обикновено има интерфейс ивнедряване Не мога да помогна да мисля, че това може да се използва и за HTTP. т.е. имате реализация на DAO за CRUD срещу базата данни и друга реализация на DAO за достъп до CRUD API. Но ако тя също се използва така, тогава какво е често срещаният начин за решаване на проблема, че може да нямате разрешения за изтриване в API?
Това правилно ли е или защо трябва да имам интерфейс за това? или това е просто, за да ми позволи лесно да променя внедряването на база данни?
Отговори:
1 за отговор № 1Моделът DAO обикновено се използва за отделянеразлични форми на представяне на данни; например, отделете схема на базата данни от логиката на приложението Java. Интерфейсите (в смисъла, който мисля, че обсъждате) обикновено се използват за отделяне на реализацията на Java логиката от нейното внедряване. Тези две форми на разделяне са напълно различни и няма причина да не се използват и двете заедно, ако това прави дизайна по-поддържан или изразителен. Дори ако Java кодът е предназначен за общо предназначение (например в някоя библиотека за многократна употреба) , тогава не мисля, че е задължително да се определя нейното поведение чрез интерфейси, въпреки че по този въпрос има различни гледни точки.
Що се отнася до вашия конкретен въпрос: ако имате методи на Java, които работят върху данни, и тези операции може да се провалят, тогава условно ще хвърлите изключение. Ако използвате DAO и част от вашата логика Java е силно отделена от реализацията на съхранение на данни, тогава тази логика може дори да не разпознае „достъп отказан“ като смислена концепция. В такива случаи трябва да отделите изключенията и вашата логика DAO да хвърли общо изключение „актуализация не е успешна“. Това изключение може да носи оригиналното изключение („отказан достъп“), дошъл от конкретната реализация на хранилището до неговия обаждащ се, което може или не може да има някакъв смисъл от това. Една от опасностите от широкото отделяне е, че обработката на грешки става все по-неспецифична, колкото повече получавате от източника на грешката.