테이블의 레코드를 기반으로 비즈니스 논리를 구현하려고합니다. 우리에게는 두 가지 선택이 있습니다.열거 형 vs 구성 파일
한 가지 방법은 테이블의 각 레코드에 대한 코드에서 enum을 만들고 코드에서 enum을 읽기 레코드와 비교하여 다음에 오는 논리를 결정하는 것입니다. 이 시스템의 단점은 키가 테이블에서 변경되면 (예 : 자동 숫자 필드에서) 변경 사항을 반영하기 위해 응용 프로그램을 다시 컴파일해야한다는 것입니다.
두 번째 방법은 변수를 테이블의 각 레코드에 대한 구성 파일에 저장하고 코드에서 구성 변수를 읽기 레코드와 비교하여 다음에 오는 논리를 결정하는 것입니다. 이 시스템에서의 drwback은 config 파일을 조작 할 수 있고 응용 프로그램이 작동을 멈출 수 있다는 것입니다.
이 문제에 가장 적합한 프로그래밍 패턴은 무엇입니까?
모든 것을 함께 보관하고 다음에 오는 비즈니스 레코드 테이블을 알려주는 테이블을 데이터베이스에 저장하지 않는 이유는 무엇입니까?
죄송합니다. 더 나은 답변을 드릴 수 없습니다. 비즈니스 논리에서 수행하려고하는 작업과 이러한 레코드의 순서에 대한 자세한 정보가 필요합니다.
나는 첫 번째 접근 방식을 선호합니다. 논리가 autonumber 필드를 변경하기 위해 충분히 변경된 경우 (이전 레코드를 삭제하거나 새 레코드를 추가하여) 새로운 패러다임을 반영하기 위해 코드를 변경해야합니다.
열거 형은 고정되어 있고 변경되지 않아야합니다. 열거 형을 변경해야하는 솔루션이있는 경우 열거 형은 잘못된 솔루션입니다.
외부 설정에서 언급 한 문제가 발생하므로 항상 좋은 선택이 아닙니다. 이를 돕기 위해 쉽게 수정할 수 있도록 암호화 할 수 있습니다.
또 다른 대안은 config 파일을 리소스로 사용하여 쉽게 수정할 수없는 리소스 DLL을 만드는 것입니다. 변경이 필요한 경우 리소스 dll을 컴파일하고 전체 응용 프로그램 만 배포하면됩니다.
Scott Langham이 데이터베이스의 구성 테이블을 사용하여 언급했습니다. 이것은 또한 좋은 생각입니다. 설치와 관련하여 가능한가요?
상태 패턴과 비슷합니다. 귀하의 응용 프로그램에있는 각 상태 (ID, 이름) 및 논리를 저장하는 테이블을 가지고 있다고 상상해보십시오. 상태 ID가 주어지면 논리를 실행해야합니다. 올바른 상태를 인스턴스화하는 방법을 해결해야합니다. ORM을 사용하는 경우 판별 자 (이 경우 상태 ID)를 사용할 수 있습니다.
+1 이것은 합리적인 대안입니다 –
+1 미안하지만 당신의 대답을 undestand하지 않았다 .. –
하지만 또한 갈 방법입니다 –