Tôi phải bắt đầu một dự án cỡ trung bình trong Java, nhưng tôi không phải là một fan hâm mộ lớn của ORM nói chung vì vậy câu hỏi là: Tôi có nên thiết kế dự án với một ORM trong tâm trí (để sử dụng sau này) hay không?ORM: Có hoặc không?
RDBMS là Oracle 10g và các truy vấn sẽ là rất kết hợp với cú pháp/hàm Oracle (ví dụ: văn bản, khai thác, CONNECT BY, v.v ...).
Thanks a lot.
Bạn có thể muốn nhìn vào câu hỏi này trước đây thảo luận về những lợi ích của ORMs: What are the advantages of using an ORM?
Phần phù hợp nhất (lấy từ câu trả lời được chấp nhận):
Nếu bạn có phức tạp, tay đã điều chỉnh SQL, không có nhiều điểm khi sử dụng ORM.
Nếu bạn liên tục tiếp cận ORM và viết SQL của riêng bạn, ORM có thể sẽ bị cản trở.
Nó phụ thuộc ...
Và bạn không cần phải sử dụng một ORM cho mỗi truy cập DB ...
Kể từ khi Im không được phép bình luận bài bình luận Ill bạn như thế này (thiếu điểm).
Sẽ tốt cho cuộc thảo luận TẠI SAO bạn không thích ORM.
Imo, tôi sẽ thực hiện. Và nếu bạn vì lý do nào đó, hãy tìm một truy vấn chậm bởi ORM, thì tôi sẽ tự làm. Chỉ vì bạn sử dụng ORM hầu hết các nhiệm vụ của bạn không có nghĩa là bạn phải sử dụng nó cho tất cả. Nhưng có, nó sẽ được ưa thích.
Một ưu điểm khác với ORM là nó sẽ trông rất tốt trên CV của bạn. Hầu hết các công việc đang được quảng cáo ngày nay (ít nhất là các nhà phát triển Java) yêu cầu một số kiến thức về ORM. Vì vậy, nếu bạn có cơ hội để làm việc trên một dự án tôi chọn Spring và Hibernate vì nó sẽ thực sự tăng CV của bạn.
Tôi nghĩ liên kết đến câu hỏi khác đã đề cập đến các lợi ích kỹ thuật khá tốt nên tôi sẽ không nói gì về chúng.
Đó là một điểm tốt. –
Vì vậy, sẽ đặt xuống "Nhà phát triển Oracle lõi cứng" và có thể nói rõ lý do tại sao trong một số trường hợp bạn không thực sự muốn trừu tượng ra $ 10.000 cho mỗi cơ sở dữ liệu CPU mà bạn đang sử dụng trong trường hợp bạn muốn hoán đổi nó sqlite3. –
Có. ORM có thể mất rất nhiều gánh nặng cho nhà phát triển ứng dụng; ít nhất, thiết kế với họ trong tâm trí không nên thêm nhiều gánh nặng cho thiết kế, và có thể giúp đáng kể trong tương lai nếu bạn quyết định đi với một ORM.
Giống như những người khác đã đề cập; nếu bạn phụ thuộc vào DB (quan hệ), ORM cung cấp cho litle và chỉ thêm trừu tượng không hữu ích. Nhưng quan trọng nhất: bạn (muốn) đối phó với dữ liệu như là Đối tượng hay không? Nếu có, ORM được thiết kế cho điều đó. Nếu không, tại sao bận tâm. Và bạn có thể thêm ORM sau này nếu cần - có thể mất nhiều thời gian hơn so với trả trước, nhưng làm ngược lại (loại bỏ Hibernate sau khi nó chỉ được theo cách của bạn ...) là tồi tệ hơn nhiều.
Nhưng cũng có sự khác biệt giữa ORM; iBatis có thể phù hợp hơn Hibernate, ví dụ (có những câu hỏi khác cho chủ đề cụ thể này).
Cá nhân tôi đã tìm thấy chúng (tốt, Hibernate) là một bồn rửa thời gian đáng kinh ngạc. Xa khỏi tiết kiệm thời gian, tôi đã dành quá nhiều thời gian để cố gắng tìm ra cái quái gì mà nó thực sự đang làm dưới vỏ bọc.Như những người khác đã đề cập, nếu mô hình dữ liệu của bạn phát triển vượt ra ngoài một mức độ phức tạp nhất định, có một lớp khác giữa bạn và DB chỉ tạo ra nhiều ma sát hơn. Nếu mô hình dữ liệu của bạn không phức tạp, thì bạn cũng không cần ORM.
I do khuyên bạn nên có một số loại trừu tượng để giữ SQL ra khỏi mã Java của bạn, nhưng điều đó có thể được thực hiện đơn giản với một lớp DAO và các tệp thuộc tính hoặc bất kỳ thứ gì. Ngoài ra các công cụ như IBATIS hoặc Spring JDBC có thể hữu ích, vì bạn vẫn có thể viết các truy vấn của riêng bạn, và chỉ sử dụng khung công tác để trợ giúp với tất cả mã boilerplate để xáo trộn dữ liệu giữa JDBC và các đối tượng Model của bạn.
PS: lưu ý thú vị. Trong văn phòng của tôi, chúng tôi thực sự có một bức tranh đóng khung của Gavin King mà tất cả chúng ta đều nguyền rủa trong effigy. "Hey, đó là của bạn để giải quyết vấn đề Hibernate ngày nay, vì vậy đây là Gavin". :-)
Đây chính xác là cảm giác của tôi. Hibernate giới thiệu nhiều vấn đề hơn là giải quyết. JDBC với SQL builder là cách để đi theo ý kiến cá nhân của tôi. Hãy xem trong ORM ánh sáng này với trình tạo SQL: http://mentabean.soliveirajr.com – TraderJoeChicago
Một ORM cố ý tách riêng các đối tượng làm việc của bạn khỏi cơ sở dữ liệu, tạo ra sự trừu tượng (chắc chắn là có rò rỉ). Vì vậy, bạn chỉ cần kết thúc đường hầm trở lại thông qua để khôi phục lại những gì bạn cố ý loại bỏ.
Nếu nhiều ứng dụng của bạn được thực hiện có chủ ý trong cơ sở dữ liệu, thì ORM chỉ thêm tiếng ồn vào tín hiệu của bạn - và làm giảm tín hiệu.
Lập bản đồ OR thực sự có thể là một vấn đề đối với SQL cụ thể cho cơ sở dữ liệu của bạn. Tuy nhiên, một số khái niệm về ánh xạ OR rất mạnh và sẽ làm cho việc tương tác với cơ sở dữ liệu của bạn trở nên dễ dàng hơn. Một số khái niệm chung cho nhiều OR-người lập bản đồ là:
Một công cụ tốt cho công việc của bạn có thể http://jooq.sourceforge.net , cho phép bạn tạo bất kỳ SQL nào bạn muốn (bao gồm các lựa chọn lồng nhau, các công đoàn, các phép nối phức tạp, bí danh, các thủ tục lưu sẵn, các UDT, v.v.)
Cá nhân tôi thích càng gần SQL càng tốt, vì vậy tôi sẽ sử dụng iBatis , JOOQ hoặc MentaBean. MentaBean bằng cách cung cấp một cách tiếp cận càng gần càng tốt để SQL trong khi đồng thời cung cấp rất nhiều trợ giúp với mã JDBC soạn sẵn.
ORM: Có cho bất kỳ công ty nào như phần mềm, nơi dữ liệu phức tạp ... nhiều cấp, bảng, lớp ... Nhưng ngay cả ở đây cũng có kết hợp tốt về chế độ xem NHibernate và EF6 và cơ sở dữ liệu.
Không cho bất kỳ ứng dụng đặc biệt nào. như đo lường và nơi bạn cần lưu thực sự nhiều dữ liệu, nhưng không có dữ liệu phức tạp
Với ORM có nhiều khả năng, tất cả đều tùy thuộc vào bạn muốn gì.
Là người lập bản đồ ORM thực, tôi mạnh mẽ recomment NHibernate và Fluent NH ánh xạ. Bạn cần rất nhiều nghiên cứu để đặt cùng một kiến trúc đẹp, nhưng sau đó không có gì đứng theo cách của bạn. Với sự thỏa hiệp tối thiểu, bạn sẽ có được sự linh hoạt thực sự.
EF6x (core không phải là prod. ready IMHO) được gọi là ORM, nhưng nó tạo ra gần hơn với DAL. Có một số điều bạn không thể làm hiệu quả với EF6. Tuy nhiên, đây là công cụ yêu thích của tôi cho một mô hình đọc, trong khi tôi kết hợp nó với NHibernate (nơi NH tôi sử dụng cho một mô hình DDD/ghi).
Hiện tại để hiệu suất - nó luôn luôn chuyên nghiệp và chống. Nếu bạn thâm nhập sâu hơn vào kiến trúc ORM (xem bài viết của tôi: avoid ORM bad habits) thì bạn sẽ tìm thấy những cách trực quan để làm cho nó nhanh hơn. Đây là bài viết khác của tôi về cách làm cho EF6x 5x nhanh hơn (ít nhất là cho các tình huống đã đọc): EF6.x 5x faster
"SQL phức tạp, điều chỉnh" nghĩa là gì? Tôi nghĩ ORM có thể xử lý bất cứ điều gì bạn có thể làm trong SQL. – johnny
Một ORM có thể xử lý * mọi thứ * bạn có thể làm trong SQL đặc biệt khi bạn đang xem xét một SQL cụ thể (trong trường hợp này là Oracle). Nếu bạn cần sử dụng các tính năng cụ thể của Oracle, có thể bạn sẽ cần phải viết ít nhất một vài truy vấn trong SQL chứ không phải ngôn ngữ truy vấn đối tượng của ORM. –
Các địa điểm phổ biến nhất mà tôi phải tiếp cận qua ORM và viết SQL của riêng tôi là báo cáo. Một số báo cáo có thể khá phức tạp và tôi không nghĩ rằng bất kỳ ORM nào cũng sử dụng PIVOT. – Min