Sử dụng các thành phần nhận thức dữ liệu Delphi - ưu và nhược điểm

Question

Tôi muốn biết ý kiến ​​của bạn về việc sử dụng các thành phần nhận biết dữ liệu trong các dự án. Điểm mạnh của các ứng dụng đang phát triển (win32 và web) là gì, bằng cách sử dụng Delphi và các thành phần nhận biết dữ liệu (từ bộ tiêu chuẩn của Delphi hoặc của bên thứ ba)?

Sử dụng FireBird Tôi đã làm việc rất nhiều với IBObjects, đây là bộ thành phần hoàn chỉnh và hoạt động rất tốt.

Nhưng cũng có rất nhiều RDBMS khác (MySQL, MSSQL, DB2, Oracle, SQLite, Nexus, nghịch lý, Interbase, FireBird, v.v.). Nếu bạn đã phát triển các dự án lớn, trên đó bạn đã sử dụng rất nhiều thành phần nhận thức dữ liệu, vui lòng trả lời với kiểu cơ sở dữ liệu và tên bộ thành phần nhận biết dữ liệu.

Tôi cũng quan tâm đến DB2 (AS400). Bạn đã sử dụng thành phần nào với thành công, hoặc thành phần nào thực sự là một nỗi đau để làm việc cùng?

Answer 1

Tôi nhận thấy rằng việc sử dụng các thành phần nhận thức dữ liệu sẽ dẫn đến một ứng dụng không có sự phân biệt rõ ràng giữa logic nghiệp vụ và giao diện người dùng.

Điều này là tốt cho các dự án nhỏ nhưng khi chúng phát triển lớn hơn, mã trở nên ít hơn và ít bảo trì hơn.

Tất cả các bit khác nhau của mã sự kiện (và tương tác của chúng) có thể trở thành cơn ác mộng thực sự để hiểu!

Lúc nào cũng vậy, tôi đã bỏ qua các thành phần nhận biết dữ liệu và đã chuyển sang thiết kế MVC (được mã hóa bằng tay).

Điều này đòi hỏi rất nhiều nỗ lực mã hóa phía trước nhưng kết quả (IMHO) trong một dự án duy trì, có thể mở rộng và có thể gỡ lỗi.

Answer 2

Hãy xem giải pháp ORM.

Đó là một cách tiếp cận tốt đẹp với kiến ​​trúc nhiều tầng. Xem ORM for DELPHI win32

Answer 3

Thành phần nhận biết dữ liệu Delphi không phụ thuộc vào công cụ cơ sở dữ liệu phía sau bạn đang sử dụng, vì vậy hãy sử dụng Firebird hoặc MS SQL Server hoặc Oracle hoặc những người khác không quan trọng đối với các thành phần nhận biết dữ liệu của bạn. Họ chỉ biết các thành phần nguồn dữ liệu được giao cho họ và làm tất cả các công cụ liên quan đến DB của họ thông qua đó.

Đối với tôi, nếu có thể làm được điều gì đó với các thành phần nhận biết dữ liệu một cách tốt đẹp, tôi sẽ sử dụng chúng. Đây thường là những dự án nhỏ nên được thực hiện trong một thời gian ngắn. Trong các dự án lớn hơn, tôi hoàn toàn có thể loại trừ các thành phần nhận biết dữ liệu hoặc sử dụng chúng trong các biểu mẫu chỉ được sử dụng để trình bày dữ liệu và không nhận được đầu vào của người dùng. Khi nói đến việc nhận đầu vào của người dùng, tôi có thể sử dụng các thành phần không nhận thức dữ liệu vì tôi linh hoạt hơn trong việc kiểm soát chúng và xác thực đầu vào. Tất nhiên các thành phần trong kho dữ liệu có thể vẫn hữu ích trong các kịch bản như vậy. Bạn vẫn có thể xác thực tính năng nhập của người dùng trong các sự kiện tập dữ liệu như OnBeforePost. Ngoài ra nếu bạn đang sử dụng thiết kế nhiều tầng và ứng dụng khách của bạn đại diện cho lớp trình bày dữ liệu, xác thực đầu vào của bạn được thực hiện ở tầng giữa để bạn có thể nhận dữ liệu nhập bằng các thành phần nhận biết dữ liệu trong ứng dụng khách và gửi chúng đến tầng giữa để xác nhận và xử lý tiếp.

Answer 4

Bạn có thể sử dụng Unidac hỗ trợ nhiều máy chủ cơ sở dữ liệu, bao gồm Firebird (tôi sử dụng) và có các tính năng rất đẹp.

Cùng với Remobject SDK bạn sẽ có sự kết hợp tuyệt vời giữa kiến ​​trúc n-tier và trừu tượng cơ sở dữ liệu.

Answer 5

Thành phần nhận biết dữ liệu hữu ích từ góc độ RAD và tạo mẫu, đặc biệt khi bạn thiết kế báo cáo hoặc lưới dựa trên dữ liệu. tức là bạn có thể tinker vào lúc thiết kế. Vì vậy, tôi sử dụng chúng như thế. Nhưng khi đến lúc biến nó thành mã vận chuyển, tôi hầu như luôn cắt đứt các kết nối, loại bỏ SQL khỏi các truy vấn và làm mọi thứ trong mã. Nó có thể dự đoán được nhiều hơn và có thể bảo trì theo cách đó, đặc biệt là trong môi trường đa nhà phát triển với điều khiển phiên bản. Khi SQL được nhúng trong biểu mẫu ở đâu đó, đó là một nỗi đau lớn để cố gắng tìm ra nơi mà SQL thực sự cư trú. Và nó đặc biệt tệ khi có SQL ở hai nơi, và sau đó phải tìm ra cái nào có hiệu lực.

Answer 6

Điều khiển nhận thức dữ liệu tuyệt vời, nhưng bạn phải đảm bảo bạn nhận mã doanh nghiệp của mình trong một lớp riêng biệt.

Điều đó không khó, nhưng bạn cần phải biết cách bạn có thể làm điều đó.

Một cách tiếp cận là có các thành phần Số liệu của bạn trong một DataModule (hoặc các vùng chứa hình ảnh khác).

Một mẹo hữu ích khác là sử dụng TClientDataSet để thực hiện mục nhập giao diện người dùng và sử dụng nó làm đệm trung gian giữa giao diện người dùng và lớp doanh nghiệp. Lớp nghiệp vụ sau đó sử dụng các thành phần TDataSet cụ thể cho lớp dữ liệu của bạn.

--jeroen

Answer 7

Đã thử cả kiểu dữ liệu-aware dữ liệu-aware và không ứng dụng Delphi Tôi đã trở lại trong trại thành phần dữ liệu-aware những ngày này. Phải mất một chút công việc và kỷ luật để phân lớp chính xác mã nhưng nó vẫn nhanh hơn làm mọi thứ bằng tay bằng cách sử dụng các điều khiển không nhận biết dữ liệu.

Một vài lời khuyên của tôi cho việc sử dụng thành phần dữ liệu-aware là

• Đừng chỉ viết lại FishFact trên một quy mô lớn hơn. Đặt một số suy nghĩ vào thiết kế của bạn.

• Không sử dụng TDataModule, sử dụng nhiều TDataModules mỗi phần chịu trách nhiệm về một khía cạnh nhỏ của dữ liệu ứng dụng của bạn.

• TDatasets thuộc TDataModules, trong khi TDataSources thuộc về TForms (trừ khi được sử dụng cho mối quan hệ chính/chi tiết).

• Sử dụng bộ dữ liệu trong bộ nhớ như DataSnap TClientDataSet.

• ClientDataSets của bạn không phải phản ánh chính xác bảng cơ sở dữ liệu của bạn. DataSnap cho phép bạn xoa bóp cấu trúc dữ liệu của bạn trong bộ nhớ để bạn có thể sản xuất bộ dữ liệu phù hợp cho các mục đích cụ thể. Cụ thể, bạn có thể làm những việc như

  • Gia nhập hai hoặc nhiều bảng vào một tập dữ liệu có thể chỉnh sửa

  • Denormalizing cấu trúc bảng chi tiết tổng thể, có thể đơn giản hóa mã UI của bạn đôi khi.

  • Tạo trong bộ nhớ chỉ lĩnh vực (như lĩnh vực tính toán nhưng bạn có thể viết thư cho họ cũng)

• TClientDataSet bảng lồng nhau rất hữu ích nhưng không phải là cách duy nhất để thể hiện mối quan hệ chi tiết chính. Đôi khi nó tốt hơn để làm điều đó theo cách cũ với hai TClientDataSets độc lập tham gia thông qua một TDataSource.