DAO mô hình và các đối tượng mô hình

Question

Tôi đã tra cứu rất nhiều thông tin về mô hình DAO và tôi nhận được quan điểm của nó. Nhưng tôi cảm thấy như hầu hết các giải thích không kể toàn bộ câu chuyện và do đó tôi có nghĩa là nơi bạn sẽ thực sự sử dụng DAO của bạn. Vì vậy, ví dụ nếu tôi có một lớp người dùng và một UserDAO tương ứng mà có thể lưu và khôi phục người dùng đối với tôi, đó là cách chính xác:

• Bộ điều khiển tạo ra các đối tượng người dùng và vượt qua nó để UserDAO để lưu nó vào cơ sở dữ liệu

• Bộ điều khiển tạo ra các đối tượng người dùng và trong constructor của nó đối tượng người dùng thực hiện một cuộc gọi đến userDAO để cứu bản thân vào cơ sở dữ liệu

• Đây là một mùi mã và bạn thiếu một lớp bổ sung "UserManager" mà trình điều khiển sẽ yêu cầu tạo người dùng. Các UserManager có trách nhiệm tạo cho người sử dụng và yêu cầu UserDAO để lưu nó

Tôi thực sự cảm thấy như lựa chọn thứ ba là tốt nhất, bởi vì tất cả những gì bộ điều khiển có nhiệm vụ là ủy yêu cầu đến đối tượng mô hình chính xác . Cách yêu thích của bạn là gì? Am i thiếu cái gì ở đây ?

Answer 1

Từ kinh nghiệm của tôi với DAO, cách tiếp cận đầu tiên là duy nhất đúng. Lý do là nó có trách nhiệm rõ ràng nhất và tạo ra sự lộn xộn nhất (tốt, một số lập trình viên rất đáng kính trọng coi DAO là một sự lộn xộn. Adam Bien thấy mô hình DAO ban đầu đã được triển khai trong EntityManager và các DAO khác nữa là những ống "không cần thiết")

Phương pháp tiếp cận 2 liên kết mô hình với DAO, tạo "phụ thuộc ngược dòng". Những gì tôi có nghĩa là thường là các mô hình được phân phối như các gói riêng biệt và (và nên được) không biết gì về các chi tiết của sự kiên trì của họ. Một mẫu tương tự với những gì bạn mô tả là Active Record pattern. Nó được sử dụng rộng rãi trong Ruby on Rails nhưng chưa được thực hiện với sự trang nhã và đơn giản trong Java.

Phương pháp tiếp cận 3 - điểm nào được coi là điểm của UserManager? Trong ví dụ của bạn, Người quản lý thực hiện 2 nhiệm vụ - nó có nhiệm vụ của nhà máy Người dùng và là một proxy cho các yêu cầu liên tục. Nếu đó là một nhà máy và bạn cần một nhà máy, bạn nên đặt tên nó là UserFactory mà không áp đặt các tác vụ bổ sung trên đó. Đối với proxy - tại sao bạn cần nó?

IMHO hầu hết các lớp học có tên là ...Manager đều có mùi. Tên chính nó cho thấy rằng lớp học không có mục đích rõ ràng. Bất cứ khi nào tôi có một yêu cầu để đặt tên cho một lớp học ...Manager, đó là một tín hiệu cho tôi để tìm một tên phù hợp hơn hoặc suy nghĩ kỹ về kiến ​​trúc của tôi.

Answer 2

cho webapp thông thường tôi sẽ thích chơi khung với JPA của trò chơi và triển khai cơ sở dữ liệu. Nó hiệu quả hơn nhiều.

xin hãy xem đây http://www.playframework.org/documentation/1.2.5/jpa và đây http://www.playframework.org/documentation/1.2.5/guide1 và http://www.playframework.org/documentation/1.2.5/guide2

Vậy là xong))

Answer 3

Đối tượng truy cập dữ liệu (DAO) nên được sử dụng gần hơn với lớp truy cập dữ liệu của ứng dụng của bạn. Đối tượng truy cập dữ liệu thực sự thực hiện các hoạt động truy cập dữ liệu.Vì vậy, nó là một phần của lớp truy cập dữ liệu.

Các lớp kiến ​​trúc trước DAO có thể thay đổi trong các dự án.

Bộ điều khiển cơ bản để kiểm soát luồng yêu cầu. Vì vậy, họ là loại gần với giao diện người dùng. Mặc dù, một Manager, Handler là một ý tưởng tồi, chúng ta vẫn có thể thêm một lớp giữa bộ điều khiển và DAO. Vì vậy, bộ điều khiển sẽ xử lý trước dữ liệu đến từ một yêu cầu hoặc đi ra ngoài (dữ liệu sanity, bảo mật, bản địa hóa, i18n, chuyển đổi sang JSON, v.v.). Nó sẽ gửi dữ liệu đến dịch vụ dưới dạng các đối tượng miền (Người dùng trong trường hợp này). Dịch vụ sẽ gọi một số logic nghiệp vụ trên người dùng này hoặc sử dụng nó cho một số logic nghiệp vụ. Và sau đó nó sẽ chuyển nó đến DAO.

Có logic kinh doanh trong lớp điều khiển là không tốt nếu bạn đang hỗ trợ nhiều khách hàng như JSP, WebServices, thiết bị cầm tay, vv

Answer 4

Giả sử điều khiển có nghĩa là "C" trong MVC, tùy chọn thứ ba của bạn là đúng sự tiếp cận. Nói chung Mã điều khiển mở rộng hoặc tuân theo các quy ước của một khuôn khổ. Một trong những lý tưởng của MVC là trao đổi khuôn khổ, mà thực sự là Bộ điều khiển, nên tương đối dễ dàng. Bộ điều khiển chỉ cần di chuyển dữ liệu qua lại giữa lớp mô hình và chế độ xem.

Từ góc độ mô hình, Bộ điều khiển phải tương tác với service layer - a contextual boundary - ở phía trước domain model. Đối tượng UserManager sẽ là ví dụ về một phần mà bạn sẽ xem xét một phần của lớp dịch vụ của mình - đó là API công khai của mô hình miền.

Answer 5

Cách tiếp cận đầu tiên; IMHO, bộ điều khiển gọi phương thức trên đối tượng DAO không phải là thiết kế tốt. Bộ điều khiển phải hỏi các đối tượng cấp "dịch vụ" về doanh nghiệp. Làm thế nào các "dịch vụ" vẫn tồn tại dữ liệu không phải là một mối quan tâm cho bộ điều khiển.

Cách tiếp cận thứ hai; đôi khi bạn có thể muốn chỉ tạo ra đối tượng, do đó nhiệm vụ của nhà xây dựng và trách nhiệm bền bỉ không được kết hợp chặt chẽ như thế này.

Cuối cùng, người quản lý hoặc đối tượng dịch vụ là một sự trừu tượng tốt cho kiến ​​trúc phân lớp. Bằng cách này bạn có thể nhóm các luồng nghiệp vụ trong các lớp và các phương thức thích hợp.

Nhưng đối với Play, đối tượng đồng hành của các lớp chữ thường cũng là một ứng cử viên tốt để sử dụng làm DAO. Bản chất đơn giản của những vật thể này làm cho nó trở thành một ứng cử viên tốt.

case class TicketResponse(appId: String, ticket: String, ts: String) 

object TicketResponse{ 
    implicit val ticketWrites = Json.writes[TicketResponse] 

    def save(response: TicketResponse) = { 

    val result = DB.withConnection { 
     implicit connection => 

     SQL("insert into tickets(ticket, appid, ts)" 
      + " values ({ticket},{appid},{ts})") 
      .on('ticket -> response.ticket, 'appid -> response.appId, 'ts -> response.ts).executeInsert() 
    } 

    } 

}