รูปแบบ Repository ในสถาปัตยกรรมสะอาด
นำรูปแบบ Repository มาใช้เพื่อแยกการเข้าถึงข้อมูลออกเป็นนามธรรม ทำให้กรณีใช้งานโต้ตอบกับการจัดเก็บข้อมูลได้โดยไม่ต้องทราบรายละเอียด
รูปแบบ Repository ในสถาปัตยกรรมสะอาด เป็นบทเรียน Clean Architecture & Design Patterns in Practice ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Clean Architecture & Design Patterns in Practice และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
What's the Repository Pattern?
In Clean Architecture, we want our core business logic (Use Cases) to be independent of external details like databases or web frameworks.
The Repository Pattern helps achieve this by abstracting the way data is stored and retrieved. It acts as a mediator between the domain and data mapping layers.
The Problem: Direct Data Access
Imagine your Use Case directly querying a database or calling an ORM (Object-Relational Mapper) like Hibernate or Entity Framework.
- Your Use Case becomes coupled to the database technology.
- Changing the database means changing the Use Case.
- Testing Use Cases requires a live database connection.
This violates the Dependency Rule of Clean Architecture, which states that dependencies should only point inwards.
Introducing the Repository Interface
The solution is to define an interface (a contract) for data access within your Use Case layer. This interface is the Repository.
It declares methods like findById(), save(), or findAll(). The Use Case layer owns this interface, meaning it defines what data operations it needs.
Code: User & Repository Interface
First, we define a simple User entity. Then, the UserRepository interface specifies the contract for how we'll interact with User data.
public class User {
String id;
String name;
public User(String id, String name) {
this.id = id; this.name = name;
}
public String getId() { return id; }
public String getName() { return name; }
@Override public String toString() {
return name + " (" + id + ")";
}
}
public interface UserRepository {
User findById(String id);
void save(User user);
}
public class Main {
public static void main(String[] args) {
System.out.println("User entity and UserRepository interface defined.");
}
}Repository Implementations
While the interface lives in your core domain, the concrete implementation of the Repository lives in an outer layer, typically the 'Interface Adapters' or 'Frameworks/Drivers' layer.
This implementation knows the details of the specific persistence technology (e.g., SQL database, NoSQL database, external API, or even in-memory storage).
Code: In-Memory Implementation
Here's an example of an InMemoryUserRepository. It implements the UserRepository interface using a simple HashMap, simulating a database for testing or simple applications.
// Assume User and UserRepository exist
import java.util.HashMap;
import java.util.Map;
public class InMemoryUserRepository implements UserRepository {
private final Map<String, User> users = new HashMap<>();
@Override
public User findById(String id) {
return users.get(id);
}
@Override
public void save(User user) {
users.put(user.getId(), user);
}
}
public class Main {
public static void main(String[] args) {
InMemoryUserRepository repo = new InMemoryUserRepository();
User newUser = new User("001", "Charlie");
repo.save(newUser);
User found = repo.findById("001");
System.out.println("Found user: " + found.getName());
}
}Use Cases & Repositories
A Use Case receives an instance of the UserRepository interface through dependency injection (e.g., via its constructor).
The Use Case then calls methods on this interface, completely unaware of whether it's talking to an in-memory map, a SQL database, or a remote API. This is true decoupling!
Code: Use Case with Repository
This CreateUserUseCase depends only on the UserRepository interface, not its specific implementation. This makes it highly testable and flexible.
// Assume User, UserRepository, InMemoryUserRepository exist
public class CreateUserUseCase {
private final UserRepository userRepository;
public CreateUserUseCase(UserRepository userRepository) {
this.userRepository = userRepository;
}
public User execute(String id, String name) {
User newUser = new User(id, name);
userRepository.save(newUser);
return newUser;
}
}
public class Main {
public static void main(String[] args) {
// Inject the in-memory implementation
UserRepository repo = new InMemoryUserRepository();
CreateUserUseCase createUser = new CreateUserUseCase(repo);
User createdUser = createUser.execute("002", "Diana");
System.out.println("Created user: " + createdUser.getName());
User found = repo.findById("002");
System.out.println("Verified in repo: " + found.getName());
}
}Benefits of Repositories in Clean Arch
Using the Repository Pattern offers significant advantages:
- Decoupling: Business rules are isolated from data storage details.
- Testability: Use Cases can be tested with mock or in-memory repositories.
- Flexibility: Easily swap data sources (e.g., from SQL to NoSQL) without changing core logic.
- Maintainability: Changes in data access technology are localized to repository implementations.
Quick Check on Repositories
The Repository Pattern is a cornerstone for maintaining separation of concerns in Clean Architecture.
Repository Pattern: Recap
You've learned about the Repository Pattern and its crucial role in Clean Architecture!
- It abstracts data access from your core business logic.
- It uses an interface (owned by the domain) and concrete implementations (in outer layers).
- This approach greatly enhances decoupling, testability, and flexibility.
By implementing Repositories, you ensure your Use Cases remain clean, focused, and independent of external data storage mechanisms.
เรียนรู้ Clean Architecture & Design Patterns in Practice ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 12
- บทเรียน
- 48
คำถามที่พบบ่อย
บทเรียน “รูปแบบ Repository ในสถาปัตยกรรมสะอาด” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “รูปแบบ Repository ในสถาปัตยกรรมสะอาด” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Clean Architecture & Design Patterns in Practice ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “รูปแบบ Repository ในสถาปัตยกรรมสะอาด”
นำรูปแบบ Repository มาใช้เพื่อแยกการเข้าถึงข้อมูลออกเป็นนามธรรม ทำให้กรณีใช้งานโต้ตอบกับการจัดเก็บข้อมูลได้โดยไม่ต้องทราบรายละเอียด คุณปฏิบัติ Clean Architecture & Design Patterns in Practice ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Clean Architecture & Design Patterns in Practice หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Clean Architecture & Design Patterns in Practice บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “รูปแบบ Repository ในสถาปัตยกรรมสะอาด” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Clean Architecture & Design Patterns in Practice นี้ได้ไหม
ได้ บทเรียน Clean Architecture & Design Patterns in Practice ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- รูปแบบ Repository ในสถาปัตยกรรมสะอาด
- อินเทอร์เฟซ Gateway สำหรับระบบภายนอก
- ตัวแมปข้อมูลและ DTO
- ชั้นป้องกันการปนเปื้อนสำหรับ API บุคคลที่สาม