dao-access

Define DAO interfaces to isolate data access from business logic.

2|1|Updated Jan 23, 2026

Search Tags:#testing #architecture #repository #persistence #data-access #service-layer #dao

Ready to run

npx skills add https://github.com/mpadmaraj/sample-agentic --skill dao-access

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: dao-access
Source: https://github.com/mpadmaraj/sample-agentic/tree/main/.claude/skills/dao-access
Command: npx skills add https://github.com/mpadmaraj/sample-agentic --skill dao-access

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Isolate data access concerns from business logic to enforce clean architectural boundaries and improve testability.

Core Features & Use Cases

Data retrieval and persistence through well-defined DAO interfaces.
Clear separation of concerns between data access and business rules.
Support for in-memory or mock data sources for testing.

Quick Start

Define a minimal DAO interface and implement it behind a repository, then call it from the service layer.

Frequently Asked Questions about dao-access

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

What is the DAO pattern for separating persistence concerns?▼

The Data Access Object pattern isolates persistence concerns by requiring data access logic to be free of business rules. It uses explicit interfaces with constructor-based injection to enforce a strict separation between business logic and data persistence.

How do I test service layer logic that uses repository calls?▼

You can test service layer logic by using in-memory or mock data sources for your DAO implementations. Because data access is isolated behind explicit interfaces, you can inject mocks to test business rules without hitting a real database.

Do I need constructor-based injection for DAO interfaces?▼

Yes, explicit DAO interfaces require constructor-based injection to maintain clean architectural boundaries. This approach ensures minimal persistence implementations are supplied directly, preventing hidden dependencies from leaking into the service layer.

When should I not use a Data Access Object in my architecture?▼

You should avoid using a Data Access Object if your data access logic cannot be kept free of business rules. The pattern requires strict separation, so if persistence concerns must bleed into the service layer, this approach breaks down.