2010-02-17 42 views
7

Một số thiết kế có thể có để xử lý các biểu mẫu dữ liệu thay đổi thường xuyên là gì?Tùy chọn để xử lý biểu mẫu dữ liệu thay đổi thường xuyên

Tôi có một ứng dụng web CRUD cơ bản trong đó biểu mẫu nhập dữ liệu chính thay đổi hàng năm. Vì vậy, mỗi bản ghi phải được gắn với một phiên bản cụ thể của biểu mẫu. Yêu cầu này là loại mới, do đó, các ứng dụng hiện có đã không được xây dựng với điều này trong tâm trí.

Tôi đang tìm các cách xử lý khác nhau, hy vọng tránh được nợ kỹ thuật trong tương lai. Dưới đây là một số tùy chọn tôi đã đưa ra:

  • Tạo đối tượng mới, giao diện người dùng và tập hợp bảng cho mỗi phiên bản. Đây rõ ràng là cách tiếp cận ngây thơ nhất.
  • Tiếp tục thêm tất cả các trường vào cùng một đối tượng và bảng DB, nhưng hiển thị/ẩn chúng dựa trên phiên bản biểu mẫu. Điều này sẽ trở thành một mớ hỗn độn sau một vài thay đổi.
  • Xây dựng định nghĩa biểu mẫu, sau đó tự động xây dựng giao diện người dùng và lưu trữ dữ liệu dưới dạng một số từ điển như định dạng (ví dụ: JSON/XML hoặc có thể là cơ sở dữ liệu theo định hướng tài liệu) Tôi nghĩ điều này sẽ quá phức tạp đối với phạm vi của ứng dụng này, đặc biệt cho giao diện người dùng.

Có khả năng nào khác? Có ai có kinh nghiệm làm việc này không? Tôi đang tìm một số mẫu thiết kế để giúp giải quyết sự phức tạp.

+0

Thực sự là một câu hỏi hay. Một khu vực của nó cần phải nhìn vào. Chắc chắn là +1. – Kangkan

Trả lời

0

Đối với ứng dụng cụ thể này, chúng tôi quyết định giải quyết vấn đề như thể có một hình thức liên tục phát triển. Do bản chất của hình thức này dường như tự nhiên hơn tách biệt rõ ràng hơn. Chúng tôi sẽ có một bản đồ của năm-> lĩnh vực cho các phần của ứng dụng mà cần phải biết dữ liệu nào cho năm nào.

Đối với giao diện người dùng, chúng tôi sẽ tạo trang mới cho biểu mẫu của mỗi năm. Tạo biểu mẫu động quá phức tạp trong tình huống này.

2

Trước tiên, tôi sẽ nói với các giải pháp của bạn ở trên và sau đó tôi sẽ đưa ra câu trả lời.

  • Tạo một bảng mới cho mỗi phiên bản là sẽ yêu cầu mới lập trình mỗi năm kể từ khi bạn sẽ không thể để tự động tham gia vào bảng mới và bao gồm các cột mới một cách dễ dàng. Điều đó có vẻ khá rõ ràng và thực sự làm cho đây là một lựa chọn tồi.
  • Các vấn đề bạn đã đề cập khi thêm các cột vào cùng một biểu mẫu là
    chính xác. Ngoài ra, bất kỳ cơ sở dữ liệu nào bạn đang sử dụng có tối đa số lượng cột có thể xử lý và số lượng byte có thể có liên tiếp. Điều đó có thể trở thành một mối quan tâm khác.
  • Tùy chọn thứ ba tôi nghĩ là gần nhất với những gì bạn muốn. Tôi sẽ không lưu trữ dữ liệu cột mới trong một JSON/XML trừ khi nó là để sao chép để tăng tốc độ. Tôi nghĩ rằng đây là tùy chọn tốt nhất của bạn
  • Tùy chọn duy nhất bạn không đề cập đến đã lưu trữ tất cả dữ liệu trong trường cơ sở dữ liệu 1 và sử dụng XML để phân tích cú pháp. Tùy chọn này sẽ làm cho nó trở thành khó khăn khi truy vấn và viết báo cáo chống lại.

Nếu tôi có để làm điều này:

  1. Bảng đầu tiên sẽ có cột ID (hạt), Tên, InputType, Tạo ngày, ExpirationDate, và CssClass. Tôi sẽ gọi nó là tbInputs.
  2. Bảng thứ hai sẽ có có 5 cột, ID, Input_ID (với FK để tbInputs.ID), Entry_ID (với FK để chính bảng/gốc) giá trị, và Tạo ngày. Bảng FK đến bảng chính/nguyên bản sẽ cho phép bạn để tìm mục nào được đính kèm với mục nhập biểu mẫu nào. Tôi sẽ gọi số này là bảng tbInputValues.
  3. Nếu bạn không có kế hoạch có bảng cơ sở đó thì Tôi sẽ sử dụng bảng đơn giản theo dõi ngày tạo, ID người tạo, và form_id.
  4. Một khi bạn có những thứ đó, bạn chỉ cần tạo một biểu mẫu động để kéo tất cả các đầu vào hiện đang hoạt động và hiển thị chúng. Tôi sẽ đặt tất cả các điều khiển động bên trong một số loại container như một <div> vì nó sẽ cho phép bạn lặp qua chúng mà không biết tên của mọi phần tử. Sau đó chèn vào tbInputValues ​​ID của đầu vào và giá trị của nó.
  5. Tạo biểu mẫu để thêm hoặc xóa đầu vào . Điều này có nghĩa là bạn sẽ không có nhiều nếu bất kỳ bảo trì hoạt động để làm mỗi năm.

Tôi nghĩ giải pháp này có vẻ không hùng biện nhất nhưng nếu được thực hiện đúng, tôi nghĩ đó là giải pháp linh hoạt nhất của bạn đòi hỏi số tiền nợ kỹ thuật ít nhất.

+0

Nói chung, đây là điều tôi muốn nói ở điểm thứ ba. Một nhược điểm nữa là dạng phức tạp hơn yêu cầu mã phức tạp hơn để tạo ra biểu mẫu. ví dụ. các lĩnh vực phụ thuộc vào nhau, xác nhận phức tạp –

+0

Tôi nghĩ rằng bạn đang đi vào một khu vực khá phức tạp nói chung. Tôi không biết nếu có bất kỳ câu trả lời dễ dàng nào. Bạn đã xem để xem liệu có bất kỳ điều khiển nào tồn tại để tải xuống sẽ giải quyết được sự cố của bạn không? –

+0

Tôi không mong đợi một giải pháp dễ dàng. Và mọi ứng dụng với yêu cầu này cũng sẽ khác nhau. Đó là lý do tại sao tôi bắt đầu cuộc thảo luận này. Tôi đã dành một chút thời gian để tìm kiếm giải pháp, nhưng tôi nghĩ sẽ rất khó để trang bị thêm một thứ gì đó tương tự như vậy trên mã hiện có. Có lẽ đối với một người mới bắt đầu thì đây sẽ là con đường để đi.Tôi cũng có một thời gian khó tưởng tượng một giải pháp chung cho trải nghiệm người dùng tốt như các biểu mẫu được mã hóa bằng tay. –

2

Tôi nghĩ cách tiếp cận thứ ba (XML) là linh hoạt nhất. Một cấu trúc XML đơn giản được tạo ra rất nhanh và có thể dễ dàng được phiên bản và xác nhận hợp lệ với một XSD.

Bạn sẽ có bảng giữ XML trong một cột và năm/phiên bản xml này áp dụng cho.

Tạo mã giao diện người dùng dựa trên lược đồ về cơ bản là ý tưởng tồi. Nếu bạn không yêu cầu xác thực mở rộng, bạn có thể chọn một bảng có thể chỉnh sửa đơn giản.

Nếu bạn cần một biểu mẫu tùy chỉnh mỗi năm, tôi sẽ xem xét nó như một loại bảo đảm việc làm :-) Điều quan trọng là làm cho cơ chế phiên bản và tiện ích mở rộng minh bạch và rõ ràng.

+0

Một điểm rất tốt về việc sử dụng XSD để xác thực cấu trúc XML. –

Các vấn đề liên quan