Tôi có nên sử dụng tệp cấu hình hoặc cơ sở dữ liệu để lưu trữ các quy tắc kinh doanh không?

Gần đây tôi đã đọc Lập trình viên thực dụng nói rằng:

Chi tiết làm rối tung mã nguyên sơ của chúng tôi, đặc biệt nếu chúng thay đổi thường xuyên. Mỗi khi chúng tôi phải đi vào và thay đổi mã để điều chỉnh một số thay đổi trong logic kinh doanh, hoặc theo luật hoặc theo thị hiếu cá nhân của ban quản lý, chúng tôi có nguy cơ phá vỡ hệ thống của Giới thiệu về một lỗi mới.

Săn, Andrew; Thomas, David (1999-10-20). Lập trình viên thực dụng: Từ Journeyman đến Master (Địa điểm Kindle 2651-2653). Giáo dục Pearson (Hoa Kỳ). Phiên bản Kindle.

Tôi hiện đang lập trình một ứng dụng web có một số mô hình có các thuộc tính chỉ có thể từ một tập hợp các giá trị, ví dụ (không phải là ví dụ thực tế như dữ liệu ứng dụng web được bảo mật):

ánh sáng-> loại = hình cầu / khối / hình trụ

Loại ánh sáng chỉ có thể là ba giá trị trên nhưng theo TPP, tôi phải luôn mã như thể chúng có thể thay đổi và đặt giá trị của chúng trong tệp cấu hình. Vì có một số sự cố về điều này trong suốt ứng dụng, câu hỏi của tôi là:

Tôi có nên lưu trữ các giá trị như thế này trong:

• một tập tin cấu hình:
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• một bảng trong cơ sở dữ liệu với một dòng cho mỗi mục cấu hình

• một cơ sở dữ liệu với một bảng cho mỗi mục cấu hình (ví dụ bảng: light_types; cột: id, name)

• một số cách khác?

Rất cám ơn cho bất kỳ sự trợ giúp / chuyên môn được cung cấp.

Câu hỏi tương tự xuất hiện trong hầu hết các dự án tôi làm. Thông thường, tôi làm điều này:

1. Nếu tập hợp các giá trị có thể không có khả năng thay đổi sớm, tôi sử dụng các hằng số lớp / giao diện hoặc enum trong mã và các trường liệt kê trong cơ sở dữ liệu. Ví dụ: trạng thái xuất bản các mục blog: 'không được xuất bản', 'dưới sự kiểm duyệt', 'đã xuất bản', v.v.
2. Các giá trị có thể sẽ thay đổi, nhưng các thay đổi sẽ không ảnh hưởng đến các tệp cấu hình logic chương trình. Ví dụ: danh sách "làm thế nào bạn tìm thấy trang web của chúng tôi?" tùy chọn cho một danh sách thả xuống trong hình thức mua hàng trực tuyến.
3. Các giá trị có thể thay đổi thường xuyên và / hoặc được chỉnh sửa bởi những người không phải là nhà phát triển, nhưng những thay đổi này sẽ không ảnh hưởng đến logic - cơ sở dữ liệu hoặc ít nhất là lưu trữ giá trị khóa với một số giao diện thân thiện với người dùng để chỉnh sửa.
4. Thay đổi các giá trị sẽ ảnh hưởng đến logic - có thể hệ thống cần thiết kế lại (thường là đúng) hoặc một số công cụ quy tắc kinh doanh là cần thiết. Trường hợp khó khăn nhất tôi từng thấy cho đến nay là người xây dựng bài kiểm tra tâm lý mà đồng nghiệp của tôi đã làm việc. Mỗi loại bài kiểm tra có thể có hệ thống tính điểm riêng, có thể thay đổi từ việc thêm đơn giản vào nhiều thang đo đặc điểm với các giá trị dương và âm hoặc thậm chí đánh giá câu trả lời của con người. Sau một số cuộc thảo luận về dự án này, chúng tôi đã kết thúc việc sử dụng Lua làm công cụ viết kịch bản, điều này hoàn toàn mâu thuẫn với khả năng của những người không phải là nhà phát triển để tạo ra các thử nghiệm mới (mặc dù Lua là ngôn ngữ tương đối đơn giản mà bạn không nên nghĩ rằng không phải là lập trình viên sẽ học nó).

Về báo giá từ TPP. Tôi nghĩ điều đó đúng với mã nguyên sơ , nhưng trong cuộc sống thực, bạn tốt hơn nên bắt đầu đơn giản ( nguyên tắc KISS ) và thêm các tính năng sau nếu chúng thực sự cần thiết ( YAGNI ).

Nếu dữ liệu của bạn sẽ nằm trong cơ sở dữ liệu, tôi khuyên bạn nên có một bảng 'light_types' trong cùng một DB. Điều này cung cấp cho bạn khả năng sử dụng các khóa ngoại để thực thi một ràng buộc rằng loại ánh sáng-> chỉ có thể là một trong những giá trị đó, vì vậy ngay cả khi mã bị rối, dữ liệu trong DB sẽ luôn hợp lệ.

Nếu dữ liệu sẽ không được lưu trữ trong DB, việc tạo dữ liệu chỉ cho một loạt các enum không làm được gì nhiều. Tôi có thể đề xuất một tệp cấu hình, nếu bạn thực sự muốn tránh mã hóa cứng các giá trị.

(Tuy nhiên, tôi cảnh báo không nên đi quá xa trong việc tránh mã hóa cứng. Trong bất kỳ hệ thống không tầm thường nào, sẽ có những giả định về các quy tắc và yêu cầu kinh doanh, cho dù các tác giả có nhận ra hay không. các giả định và mã mềm hoàn toàn là tất cả mọi thứ, về cơ bản bạn chỉ cần kết thúc với một "công cụ quy tắc", một loại hệ thống trong hệ thống và / hoặc ngôn ngữ meta, và bạn có một loạt các thứ trong ngôn ngữ meta Thực hiện các quy tắc. Bạn chưa lưu bất kỳ công việc nào hoặc có được sự linh hoạt; bạn chỉ cần xây dựng và / hoặc học một ngôn ngữ khác.

Bây giờ, nếu bạn muốn tìm và sử dụng một công cụ quy tắc hiện có, điều đó có thể giúp bạn tiết kiệm một chút công việc (cùng với việc trả lời câu hỏi về nơi lưu trữ enum). Nhưng việc xây dựng của riêng bạn chỉ làm tăng gấp đôi khối lượng công việc và chắc chắn sẽ mang lại cho bạn một hệ thống nửa vời được xây dựng bởi những người thực sự không biết cách tạo ra một công cụ quy tắc hợp lý.)

Nói chung, cơ sở dữ liệu nên được sử dụng cho dữ liệu và nên sử dụng tệp cấu hình để cấu hình. (như tên cho thấy :)). Giữ cấu hình trong cơ sở dữ liệu là sự phân tách mối quan tâm xấu và chỉ nên được thực hiện nếu bạn có một trường hợp sử dụng tốt để biện minh cho nó.

Có một sự cân bằng được đưa ra khi quyết định sử dụng bao nhiêu cấu hình. Bạn nên coi các tệp cấu hình của mình giống như một phần của ứng dụng như mã. Giữ nó càng ngắn càng tốt. Rất dễ dàng cho các ứng dụng bị ảnh hưởng bởi sự phình to cấu hình nơi bạn kết thúc với một tệp xml khổng lồ chứa đầy chuỗi ma thuật.

Trong trường hợp bạn mô tả, sẽ hợp lý khi có một thành phần cấu hình để xác định tệp css nào sẽ sử dụng. (sau đó bạn có thể thay đổi nó nếu yêu cầu thay đổi). Sẽ là quá mức khi định cấu hình kiểu của từng thành phần trong tệp cấu hình