2

내 응용 프로그램 (ASP.NET MVC 3.0 RTM, Razor View Engine)의 경우 내 모델에 DataAnnotations를 사용하고 싶습니다. 웹 프로젝트 내에서 모델 클래스를 유지한다면 .resx.resources 개의 파일에 임베드하지 않고 App_GlobalResources 또는 App_LocalResources에 resx 리소스를 가질 수 있습니다.클래스 라이브러리의 DataAnnotations 및 Resx

새로 생성 된 AppDomains 및 기타 고려 사항을 무시하면 오타 또는 잘못된 변환과 같은 현지화 된 리소스의 사소한 변경 사항이 컴파일 할 필요가 없으므로 이는 이상적입니다.

그러나 모델을 클래스 라이브러리로 이동 한 후에 .resx 파일을 출력으로 유지하고 DataAnnotations 특성을 계속 사용하는 방법이 없습니다. 내가 놓친 게 있니?

문제는 속성이 자원을 찾는 방식에 있습니다. 예를 들어, "이름"속성은 다음과 같습니다 강력한 형식의 자원 랩퍼

[Display(Name = "MyEntity_Name", ResourceType = typeof(Validations))] 
    [Required(ErrorMessageResourceName="MyEntity_Name_Required", 
     ErrorMessageResourceType = typeof(Validations))] 
    [StringLength(150, MinimumLength = 2)] 
    public string Name { get; set; } 

이 요구 사항은 지난 24 시간 동안 내 존재의 파멸이되고있다.

랩퍼를 일반화하려고 시도했지만 유효성 검사 특성에서 DisplayAttribute에 대해 MyEntity_Name이라는 랩퍼의 속성을 찾고, RequiredAttribute에 MyEntity_Name_Required이라는 속성이있는 것처럼 보입니다. 필자는 DataAnnotations 코드에 대해 더 깊이 파고 들지 않아서 내가 할 수있는 마술이 있는지 확인했습니다. 나는 다른 누군가가 이것을 만나고 아이디어를 얻길 바랐다.

[질문
그것은 .resources 파일로 RESX 파일을 포함시키지 않고 클래스 라이브러리 (DisplayAttribute 포함) DataAnnotations의 ValidationAttributes를 사용할 수 있습니까?

미래에 둘점 :(
을, 나는 아주 최소한의 코딩 노력으로 데이터베이스 기반 리소스에 RESX에서 이동하고 싶습니다. 나는 그 지금 때문에 제한된 자원 (웃기 할 수 없습니다) 의도. 그래서, 나는 ResourceProvider를 우회하지 않도록합니다. 또한, 나는 다시 작성하거나 System.ComponentModel.DataAnnotations 네임 스페이스의 모든 속성을 포장하지 않도록합니다.

+0

WebForms보기의 컴파일 타임 리소스는 'Content'빌드 동작으로 .resx에서 가져 오는 것처럼 보입니다. 그렇지 않으면 어쨌든 DataAnnoations에서 '포함 리소스'로 표시해야합니다. –

답변

3

내가 뭔가를 놓치고 있습니까?

예, 그렇습니다. 보기 모델이 누락되었습니다. 컨트롤러 액션은 모델이 아닌 뷰 모델을 뷰에서 가져 오거나 통과합니다. 뷰 모델은 특정 뷰의 요구에 맞게 조정 된 클래스입니다. 여기에는 필수 속성과 주어진보기에 적합한 형식이 포함되어 있습니다. 뷰 모델은 모델의 하위 집합이거나 여러 모델의 집합 일 수 있습니다 (뷰의 요구 사항에 따라 다름). 뷰 모델은 뷰에 매우 밀접하게 결합되어 있기 때문에 항상 웹 프로젝트에 정의됩니다. 따라서 리소스로 지역화/글로벌화해야하는 뷰 모델입니다. 워크 플로우의

예는 :

  1. 컨트롤러 조치가 호출되고이 컨트롤러는 해당 뷰 모델에 모델을 매핑하는 모델을
  2. 를 가져 저장소를 조회
  3. (AutoMapper 여기 수) 컨트롤러는 뷰 모델을 뷰에 전달하고 뷰는 적절한 포매팅/로컬 리 제이션을 통해 뷰를 표시합니다.

결론 : 모델을 형식화하거나 현지화하지 마십시오. 재사용하기가 더 어려워집니다.

+0

우리 팀에서는 ViewModels를 프레젠테이션 레이어 외부로 옮겨서 MVC 프레임 워크를 일반적으로 악용하는 것에 대한 우려를 제기했습니다. 검증을 중앙 집중식으로 유지하기를 원했기 때문에 내 관심은 일반적으로 (아직 우스꽝스럽게) 으 sh 해졌다. 프레젠테이션 계층과 다음 계층에서 유효성 검사의 복잡성을 관리하는 올바른 방법은 무엇입니까? 필자가 취해야 할 점은 UI 검증이 있고 다음 계층에서 다시 검증 할 Web Forms과 다르지 않다는 것이다. –

+1

@ 짐. 유효성 검사를 중앙 집중식으로 유지하기가 어렵습니다. 예를 들면 다음과 같습니다.보기 추가/업데이트를 가정합니다. 'Add' 뷰에는'Id' 속성이 없습니다. 삽입하고 있기 때문에 걱정하지 않아도됩니다. 기존 엔티티를 수정하기 때문에'Update' 뷰에서'Id' 속성이 필요합니다. 유효성 검사 규칙이 변경되는보기에 따라 방법을 볼 수 있습니까? 그래서 개인적으로 모델의 뷰 모델 및 비즈니스 유효성 검증 (형식화, 필수, ...)에 대한 모든 간단한 유효성 검증을 수행합니다 (사용자 이름은 이미 사용되었습니다 ...). 덕분에 –

+0

. 검증에 대한 필자의 생각과 거의 유사합니다. 나는 팀에서 다른 사람들과 토론해야 할 것이지만, 내가 미치지 않았다는 것을 알면 좋다. –