Tạo giao diện người dùng từ DB - hàng hóa tốt, xấu và xấu?

Question

Tôi đã đọc một câu lệnh ở đâu đó tạo giao diện người dùng tự động từ bố cục DB (hoặc đối tượng kinh doanh hoặc bất kỳ lớp kinh doanh nào khác) là một ý tưởng tồi. Tôi cũng có thể tưởng tượng ra một vài thử thách tốt mà người ta phải đối mặt để tạo ra một thứ như thế này.

Tuy nhiên tôi chưa thấy (cũng không thể tìm thấy) bất kỳ ví dụ nào về những người đang cố gắng. Vì vậy, tôi tự hỏi - là nó thực sự là xấu? Nó chắc chắn không dễ dàng, nhưng nó có thể được thực hiện với bất kỳ biện pháp thành công? Những trở ngại chính là gì? Nó sẽ là tuyệt vời để xem một số ví dụ về những thành công và thất bại.

Để làm rõ - với "tạo giao diện người dùng tự động", nghĩa là tất cả các biểu mẫu có tất cả các điều khiển của chúng được tạo tự động hoàn toàn (vào thời gian chạy hoặc biên dịch), có lẽ dựa trên một số gợi ý về siêu dữ liệu về cách dữ liệu được biểu diễn. Điều này trái ngược với việc thiết kế các biểu mẫu bằng tay (như hầu hết mọi người đều làm).

Added: Tìm thấy this somewhat related question

Added 2: OK, có vẻ như một trong những cách này có thể nhận được kết quả khá công bằng là nếu đủ metadata trình bày liên quan đến có sẵn. Đối với phương pháp này, bao nhiêu sẽ là "đủ", và nó sẽ được bất kỳ công việc ít hơn so với thiết kế các hình thức bằng tay? Liệu nó cũng cung cấp sự linh hoạt lớn hơn cho những thay đổi trong tương lai?

Answer 1

Chúng tôi đã có một dự án sẽ tạo ra các bảng cơ sở dữ liệu/proc được lưu trữ cũng như giao diện người dùng từ các lớp học kinh doanh. Nó được thực hiện trong .NET và chúng tôi đã sử dụng rất nhiều Thuộc tính tùy chỉnh trên các lớp và thuộc tính để làm cho nó hoạt động theo cách chúng tôi muốn. Mặc dù nó hoạt động rất tốt và nếu bạn quản lý theo thiết kế của mình, bạn có thể tạo các tùy chỉnh phần mềm của bạn một cách dễ dàng. Chúng tôi cũng đã có cách để đưa các điều khiển người dùng "tùy chỉnh" vào một số trường hợp rất đặc biệt.

Tất cả trong tất cả đều hiệu quả với chúng tôi. Thật không may nó là một sản phẩm ngân hàng bán và không có nguồn sẵn có.

Answer 2

hey điều này không khó để đạt được chút nào và không phải là một ý tưởng tồi chút nào. tất cả phụ thuộc vào nhu cầu của dự án của bạn. rất nhiều sản phẩm phần mềm (tâm trí bạn không dự án nhưng sản phẩm) phụ thuộc vào mô hình này - vì vậy họ không phải viết lại mã của họ/logic ui cho các nhu cầu khách hàng khác nhau. khách hàng có thể tùy chỉnh giao diện người dùng theo cách họ muốn sử dụng biểu mẫu thiết kế trong hệ thống quản trị

tôi đã sử dụng xml để lưu trữ dữ liệu meta cho loại nội dung này.một số các thuộc tính mà tôi lưu lại cho mọi lĩnh vực là:

1. friendlyname (nhãn caption)
2. haspredefinedvalues ​​(có cho thả xuống danh sách/đa kiểm tra hộp danh sách)
3. multiselect (nếu có thì đánh dấu vào ô danh sách, nếu không thì danh sách thả xuống)
4. datatype
5. maxlength
6. cần
7. minvalue
8. maxvalue
9. biểu thức chính quy
10. kích hoạt (để hiển thị hoặc không hiển thị)
11. sortkey (thứ tự trên mẫu web)

về vị trí - tôi không quan tâm nhiều và chỉ đơn giản là tạo ra bảng tr td thẻ 1 bên dưới khác - tuy nhiên nếu bạn muốn thực hiện điều này là tốt, bạn có thể có thêm 1 thuộc tính được gọi là CssClass nơi bạn có thể xác định thuộc tính cụ thể ui (giao diện, vị trí, v.v.) tại đây

CẬP NHẬT: cũng lưu ý rất nhiều sản phẩm thương mại điện tử theo loại ui động này khi bạn muốn nhập thông tin sản phẩm - vì khách hàng của họ có thể bán mọi thứ dưới ánh mặt trời từ đồ nội thất đến đồ chơi tình dục ;-) thay vì viết lại mã của họ cho mọi ngành công nghiệp khác nhau họ chỉ đơn giản cho phép khách hàng của họ nhập dữ liệu meta cho thuộc tính sản phẩm thông qua biểu mẫu quản trị :-)

tôi cũng khuyên bạn nên xem Entity-attribute-value model - nó có ưu và khuyết điểm riêng của nó nhưng tôi cảm thấy nó có thể được sử dụng khá tốt với yêu cầu của bạn.

Answer 3

nó ok cho một cái gì đó nhỏ bé nơi mà tất cả bạn cần là một phương pháp thực dụng để có được các dữ liệu trong.

cho bất cứ điều gì giống như một ứng dụng thực tế, mặc dù nó là một ý tưởng khủng khiếp. những gì làm cho một giao diện người dùng tốt là yếu tố nhân bản, các bit bạn tinh chỉnh để đảm bảo rằng máy này phản ứng tốt với liên lạc của một người.

bạn không thể có được điều đó khi giao diện của bạn được tạo ra một cách máy móc .... cũng có thể với thứ gì đó đang tiếp cận AI. :)

chỉnh sửa - để làm rõ: Giao diện người dùng được tạo từ mã/db là tốt như điểm bắt đầu, nó chỉ là điểm kết thúc rác.

Answer 4

Theo tôi có một số điều bạn nên suy nghĩ về:

1. Liệu khách hàng cần một chức năng để tùy chỉnh giao diện người dùng của mình?
2. Có nhiều thuộc tính hoặc yếu tố khác nhau không?
3. Nỗ lực tạo ra một "công cụ kết xuất" như vậy có xứng đáng không?

Được rồi, tôi nghĩ rằng điều này khá rõ ràng lý do bạn nên suy nghĩ về điều này. Nó thực sự phụ thuộc vào dự án của bạn nếu kiểu mô hình đó có ý nghĩa ... Nếu bạn muốn tạo một số biểu mẫu có thể được tùy chỉnh trong thời gian chạy thì mô hình này có thể khá hữu ích. Ngoài ra, nếu bạn cần phải làm rất nhiều công cụ nhỏ hơn và bạn sử dụng nó như một loại "động cơ" thì nỗ lực này có thể đáng giá vì bạn có thể tiết kiệm rất nhiều thời gian. Với loại "công cụ hiển thị" đó, bạn có thể tự động thêm các báo cáo lỗi, kiểm tra các giá trị hoặc thêm những thứ khác luôn luôn xây dựng với cùng một mẫu. Nhưng nếu bạn có quá nhiều thứ, yếu tố hoặc thuộc tính này thì hiệu suất có thể giảm nhanh chóng. Một thứ khác trở nên thú vị trong các dự án lớn hơn là, những thay đổi đó phải xảy ra ở mỗi dạng chỉ phải được thực hiện trong động cơ, không phải trong từng hình thức. Điều này có thể tiết kiệm rất nhiều thời gian nếu có một lỗi trong ứng dụng đã hoàn thành. Trong công ty chúng tôi, chúng tôi sử dụng một mô hình tương tự cho một bộ tạo giao diện giữa phần mềm tiền mặt (ngay bây giờ tôi không thể nhớ đúng từ cho nó ...) và ứng dụng của chúng tôi, nó không tạo ra giao diện người dùng, mà là đầu ra tệp cho một trong các ứng dụng. Chúng tôi sử dụng XML để xác định cấu trúc và cách các giá trị cần được chuyển đổi, v.v ..

Answer 5

Tôi sẽ nói rằng trong hầu hết các trường hợp, dữ liệu không phù hợp để tạo giao diện người dùng. Đó là lý do tại sao bạn hầu như luôn đặt một lớp logic vào giữa để diễn giải thông tin DB cho người dùng. Một điều nữa là khi bạn tạo giao diện người dùng từ DB, bạn sẽ kết thúc hiển thị các hoạt động bên trong của hệ thống, điều mà bạn thường không muốn làm.

Nhưng nó phụ thuộc vào nơi mà DB đến từ đó. Nếu nó được tạo ra để phản ánh chính xác mục tiêu người dùng của hệ thống là gì. Nếu người dùng mô hình tinh thần về những gì ứng dụng sẽ giúp họ với được lưu trữ trong DB. Sau đó, nó có thể chỉ hoạt động. Nhưng sau đó bạn có để bắt đầu ở cuối người dùng. Nếu không tôi đề nghị bạn không đi theo cách đó.

Answer 6

Bạn có thể xem xét vấn đề của mình từ phối cảnh kiến ​​trúc ứng dụng không? Tôi thấy bạn như một kẻ khủng bố cơ sở dữ liệu khác - cố gắng giải quyết tất cả bằng cách viết các thủ tục lưu sẵn. Tại sao có giao diện người dùng? Hãy thử làm điều đó trong kịch bản DB. Trong thực tế của cách tiếp cận như vậy - trên những gì hệ thống tổng hợp bạn sẽ kết thúc? Khi hệ thống phục vụ các doanh nghiệp khác nhau - hãy thử mô đun hóa, các thành phần được phát hiện có chọn lọc, hạn chế chia sẻ tài liệu tham khảo. Giao diện người dùng sẽ có thể thay thế, độc lập với lớp kinh doanh. Khi lưu trữ rất nhiều dữ liệu trong DB - có sự phụ thuộc khó khăn của UI - hệ thống trở thành nguyên khối. Làm thế nào bạn thực hiện mô hình MVVM trong kịch bản khi giao diện người dùng được tạo ra? Các nhà thiết kế như Blend có chứa rất nhiều tính năng, mà không thể được thay thế bởi hầu hết các trình tạo giao diện người dùng tương lai - trừ khi - nền tảng phát triển của bạn chỉ là Notepad.