Tôi đến từ một nền tảng java.Thực hành tốt nhất cho sự kiên trì ngay bây giờ là gì?
Nhưng tôi muốn có một quan điểm đa nền tảng về những gì được coi là thực tiễn tốt nhất cho các đối tượng bền bỉ.
Con đường tôi nhìn thấy nó, có 3 trại:
Có phải mọi người vẫn thắc mắc handcode (bỏ qua ORM)? Tại sao, xem xét các tùy chọn có sẵn thông qua JPA, Django, Rails.
Không có cách nào tốt nhất để duy trì sự kiên trì (mặc dù số người la hét rằng ORM là cách thực hành tốt nhất có thể khiến bạn tin khác). Cách tốt nhất là sử dụng phương pháp phù hợp nhất cho nhóm của bạn và dự án của bạn. Chúng tôi sử dụng ADO.NET và các thủ tục lưu trữ để truy cập dữ liệu (mặc dù chúng tôi có một số trình trợ giúp giúp viết nhanh như trình tạo lớp SP, IDataRecord cho trình dịch đối tượng và một số thủ tục thứ tự cao hơn đóng gói các mẫu phổ biến). và xử lý lỗi).
Có rất nhiều lý do cho điều này mà tôi sẽ không đi vào đây, nhưng đủ để nói rằng họ là những quyết định phù hợp với nhóm của chúng tôi và nhóm của chúng tôi đồng ý. Mà, vào cuối ngày, là những gì quan trọng.
Tôi hiện đang đọc các đối tượng bền bỉ trong .net. Vì vậy, tôi không thể đưa ra một phương pháp hay nhất, nhưng có lẽ thông tin chi tiết của tôi có thể mang lại cho bạn một số lợi ích. Cho đến một vài tháng trước, tôi đã luôn luôn sử dụng truy vấn được mã hóa, một thói quen xấu từ những ngày ASP.classic của tôi.
Linq2SQL - Rất nhẹ và dễ dàng tăng tốc. Tôi thích khả năng truy vấn được đánh máy mạnh mẽ và thực tế là SQL không được thực hiện cùng một lúc. Thay vào đó nó được thực hiện khi truy vấn của bạn đã sẵn sàng (tất cả các bộ lọc được áp dụng), do đó bạn có thể chia tách quyền truy cập dữ liệu từ việc lọc dữ liệu. Ngoài ra Linq2SQL cho phép tôi sử dụng các đối tượng miền tách biệt với các đối tượng dữ liệu được tạo động. Tôi đã không cố gắng Linq2SQL trên một dự án lớn hơn nhưng cho đến nay nó có vẻ đầy hứa hẹn. Oh nó chỉ hỗ trợ MS SQL mà là một sự xấu hổ.
Entity Framework - Tôi đã chơi xung quanh với nó một chút và không thích nó. Có vẻ như muốn làm mọi thứ cho tôi và nó không hoạt động tốt với các thủ tục được lưu trữ. EF hỗ trợ LINq2Entities lại cho phép truy vấn mạnh mẽ. Tôi nghĩ rằng nó được giới hạn trong MS SQL nhưng tôi có thể sai.
SubSonic 3.0 (Alpha) - Đây là phiên bản mới hơn của SubSonic hỗ trợ LINQ. Điều thú vị về SubSonic là nó dựa trên các tệp mẫu (mẫu T4, được viết bằng C#) mà bạn có thể dễ dàng sửa đổi. Do đó nếu bạn muốn mã được tạo tự động trông khác, bạn chỉ cần thay đổi nó :). Tôi đã chỉ thử xem trước cho đến nay nhưng sẽ nhìn vào Alpha ngày hôm nay. Hãy xem ở đây SubSonic 3 Alpha. Hỗ trợ MS SQL nhưng sẽ hỗ trợ Oracle, MySql, v.v.
Cho đến nay kết luận của tôi là sử dụng LINQ2SQL cho đến khi SubSonic sẵn sàng và sau đó chuyển sang đó vì các mẫu SubSonics cho phép tùy chỉnh nhiều hơn.
Có ít nhất một số khác: System Prevalence.
Theo như tôi có thể nói, điều tối ưu cho bạn phụ thuộc rất nhiều vào hoàn cảnh của bạn. Tôi có thể thấy làm thế nào cho các hệ thống rất đơn giản, bằng cách sử dụng các truy vấn trực tiếp vẫn có thể là một ý tưởng tốt. Ngoài ra, tôi đã thấy Hibernate không hoạt động tốt với các lược đồ cơ sở dữ liệu kế thừa phức tạp, do đó, việc sử dụng ORM có thể không phải lúc nào cũng là một tùy chọn hợp lệ. Tỷ lệ hệ thống được cho là cực nhanh, nếu bạn có đủ bộ nhớ để phù hợp với tất cả các đối tượng của bạn vào RAM. Bạn không biết về LINQ, nhưng tôi cho rằng nó cũng có sử dụng của nó.
Vì vậy, như thường lệ, câu trả lời là: biết nhiều công cụ khác nhau cho công việc, để bạn có thể sử dụng một công cụ thích hợp nhất cho tình huống cụ thể của mình.
tần suất hệ thống giả định không chính xác rằng nếu bạn có thể phù hợp với tất cả các đối tượng của bạn vào RAM, nó sẽ hoạt động nhanh. tốt, nó sẽ không. có những báo cáo mà ngay cả những người thu gom rác hiện đại cũng đi hạt khi họ phải xử lý hàng triệu vật thể. cũng như những ngày này, nếu bạn có đủ bộ nhớ trong máy chủ cơ sở dữ liệu, bạn sẽ nhận được hiệu năng tương tự và thậm chí nhanh hơn so với sử dụng hệ thống phổ biến vì cơ sở dữ liệu được tối ưu hóa cho hiệu suất. –
Phương pháp hay nhất tùy thuộc vào tình huống của bạn.
Nếu bạn cần các đối tượng cơ sở dữ liệu trong cấu trúc bảng với một số cấu trúc có ý nghĩa (vì vậy một cột cho mỗi trường, một hàng cho mỗi thực thể và vv) bạn cần một số loại lớp dịch giữa các đối tượng và cơ sở dữ liệu. Những mùa thu thành hai phe:
Nếu không có logic trong cơ sở dữ liệu (chỉ cần lưu trữ) và bản đồ bảng với các đối tượng tốt, sau đó một giải pháp ORM có thể cung cấp một hệ thống bền bỉ nhanh chóng và đáng tin cậy. Các hệ thống Java như Toplink và Hibernate là những công nghệ trưởng thành cho việc này.
Nếu có là logic cơ sở dữ liệu liên quan đến sự kiên trì hoặc lược đồ cơ sở của bạn đã trôi qua khỏi mô hình đối tượng của bạn một cách đáng kể, được liên kết nhiều hơn ORM nhưng linh hoạt hơn.
Nếu bạn không cần phải lưu trữ có cấu trúc (và bạn cần phải thực sự chắc chắn rằng bạn không, như giới thiệu nó đến dữ liệu hiện có không phải là niềm vui), bạn có thể lưu trữ đồ thị đối tượng serialized trực tiếp trong cơ sở dữ liệu, bỏ qua rất nhiều phức tạp.
Re: trại đầu tiên, tôi không đồng ý rằng nó dễ dàng hơn với một giải pháp ORM. Có rất nhiều thiết lập trong hệ thống xây dựng để làm cho nó hoạt động chính xác. – ashitaka
Tôi thích viết SQL của riêng mình, nhưng tôi áp dụng tất cả các kỹ thuật tái cấu trúc của mình và "các công cụ tốt" khác khi tôi làm như vậy.
Tôi đã viết các lớp truy cập dữ liệu, trình tạo mã ORM, các lớp kiên trì, quản lý giao dịch UnitOfWork và LOTS của SQL. Tôi đã làm điều đó trong các hệ thống của tất cả các hình dạng và kích cỡ, bao gồm các nguồn cấp dữ liệu cực kỳ hiệu suất cao (bốn mươi nghìn tệp tổng cộng 40 triệu giao dịch mỗi ngày, mỗi lần tải trong vòng hai phút của thời gian thực).
Tiêu chí quan trọng nhất là số phận, như kiểm soát chúng. Đừng bao giờ để công cụ ORM của bạn trở thành một trở ngại cho việc hoàn thành công việc của bạn, hoặc một cái cớ để không làm đúng. Cuối cùng, tất cả SQL tốt đều được viết tay và điều chỉnh bằng tay, nhưng một số công cụ phong nha có thể giúp bạn có được bản nháp đầu tiên tốt một cách nhanh chóng.
Tôi xử lý vấn đề này giống như cách tôi thiết kế giao diện người dùng của mình. Tôi viết tất cả các giao diện người dùng trực tiếp trong mã, nhưng tôi có thể sử dụng một nhà thiết kế trực quan để tạo ra một số yếu tố thiết yếu mà tôi nghĩ, sau đó tôi xé toạc mã mà nó tạo ra để tự khởi động. Vì vậy, hãy sử dụng một công cụ ORM trong bất kỳ biểu hiện nào của nó như là một cách để có được một ví dụ phong nha - xem cách nó giải quyết được nhiều vấn đề nảy sinh (tạo khóa, liên kết, điều hướng, v.v.). Xé bỏ đầu ra của nó, làm cho nó của riêng bạn, sau đó tái sử dụng heck ra khỏi nó.
Rob, Cảm ơn ý kiến của bạn. Nó rất khai ngộ. Tôi cũng thích viết SQL của riêng mình. Nhưng hầu như tất cả các dự án mà tôi tham gia, họ thích sử dụng ORM hơn. Đó là hệ thống giao dịch 40 triệu/ngày bạn đã đề cập, nền tảng nào nó đang chạy? – ashitaka
8 TB Cơ sở dữ liệu Oracle 10g trên SAN, Sun Solaris 10 trên hộp SunFire midlevel với RAM 4 GB, Java 1.6 được hiển thị qua dịch vụ web trên JBoss & WebLogic 10 –
Re: EF bị giới hạn đối với MS SQL - ngoài hộp - có, nhưng có các đối tác bên thứ ba phát triển các nhà cung cấp cho các RDBMS khác. Vì vậy, ví dụ nếu bạn muốn ORACLE thì một công ty có tên DevArt có cả nhà cung cấp EF cho ORACLE và cũng là một triển khai LINQ-to-ORACLE. – rohancragg