응용 프로그램에 대한 메시지 서비스를 구축 중입니다. 사용자는 이메일 주소 및 사용자 ID로 식별됩니다. Uid는 user 테이블의 기본 키로도 사용됩니다. 내 응용 프로그램이 사용자의 전자 메일 주소로 작업하는 것보다 해당 UID를보고 사용할 수있게하는 것이 더 빠르고 간단하다는 것을 알았습니다.애플리케이션이 데이터베이스에 대해 얼마나 알고 있어야합니까?
내 응용 프로그램이 데이터베이스 디자인에 대해 알고있는 것이 중요합니까? 이것은 구체적인 예입니다. 그러나 일반화로서의 질문을 의미합니다 ... 응용 프로그램과 데이터베이스 간의 정보 공유에 관해서 얼마나 많은 지식이 '너무 많이'입니까?
나는 무엇이 '좋은 디자인'으로 간주 될지의 관점에서 주로 묻습니다. 이 태그를 붙이는 방법을 잘 모르겠다.
응용 프로그램 및 서비스 계층은 응용 프로그램 전체에서 사용되는 "도메인"객체로 데이터를 추상화해야합니다. 데이터 검색 및 저장을 처리하는 데이터 계층 만 전체 데이터베이스 설계를 알아야합니다. 데이터를 올바르게 쿼리하고 저장하려면이 정보를 알아야합니다.
응용 프로그램 개발에 대한 표준 계층화 된 접근 방법을 따르십시오. 계층화 된 아키텍처에 대한 많은 서적이 있습니다.
이 특정 데이터베이스의 사용 범위를 넘어서이 응용 프로그램 규모를 사용할 계획이 있는지 여부에 달려 있다고 생각합니다. 지나친 일반화로 인해 코드가 필요 이상으로 복잡해지고 (그리고 덜 효율적일 수도 있음) 요점이 있다고 생각합니다. 당신은 균형을 찾을 필요가 있으며, 이는 아마도 계획된 미래의 응용에 달려있을 것입니다. 분명히 내 대답은 완전히 주관적이다.
귀하의 응용 프로그램 요구 사항을 찾는 방법에 따라 다릅니다.
좋은 디자인 중 하나는 코드를 레이어에 분리하여 코드를 재사용 할 수있게 만드는 것입니다.
Ntier : UI < - BusinessLogiclayer < - DataAccessLayer.
MVC : 모델 < ---보기 < --- 컨트롤러.
도메인/DataAccesslayer는 마치 한 클래스에 있기 때문에 언제든지 ui에서 호출 할 수 있습니다.
데이터베이스가 정상화/표준화되고 익숙해 졌는지 확인하여 응용 프로그램에서 필요한 최선의 방법이 무엇인지 확인해야합니다.