POCO + 엔티티 프레임 워크 - 나는 3 층으로 구성되어 응용 한

Question

처리 허가 :
UI : 비즈니스
ASP.NET MVC에서 구현되는이 : 비즈니스 로직 및 리소스 액세스를 보유 컨트롤
리포지토리 (DAL) : 리포지토리 패턴을 사용하여 POCO 개체와 EF로 구현됩니다. 내 POCO 개체는 상위 레이어와 공유됩니다.

POCO에게 어떤 정보/방법이 있어야합니까? 예 : 사용자의 사용자 이름과 비밀번호를 보유하고있는 사용자 테이블이있는 경우 내 POCO에 어떤 항목이 있습니까? 비밀번호를 어떻게 확인해야합니까? 내 POCO가 저장소에 유효성 검사를 요청하는 방법을 사용해야합니까?

또한 리소스에 대한 액세스를 어떻게 제어해야합니까? 내 리포지토리가 리소스에 액세스 할 수있는 사용자와 액세스 할 수없는 사용자를 제어해야합니까? 그래도 내 POCO는 탐색 속성으로 정보를 노출 할 수 있습니다. 현재 사용자가 POCO propoertise를 사용할 수 있는지 확인해야합니까?

미리 감사드립니다.

Answer 1

비슷한 프로젝트가 있는데 비슷한 작업을 수행하는 방법에 대한 세부 정보를 제공 할 수 있습니다. 귀하의 전체 솔루션이 .Net 기반이라고 가정합니다.

POCO (일반 오래된 CLR 개체)는 비즈니스 논리가없는 개체입니다. 따라서 암호 유효성 검사는 해당 클래스에서 직접 수행하지 말고 비즈니스 계층에 적용해야합니다. 예를 들어, UI는 컨트롤러 조치를 호출하여 비즈니스 계층 (BL)에 데이터를 제출하고, BL은 현재 저장된/암호화 된 암호를 얻기 위해 저장소를 호출하여 BL 사용자 암호 유효성 검사를 수행하고, BL은 암호를 비교하여 결과를 UI에 적용하거나 다른 조치를 취하십시오. 물론 모든 데이터는 SQL injection이나 Cross Site Scripting 공격을 막기 위해 유효성을 검사해야합니다.

POCO에는 Uid/Pwd 속성이있을 수 있습니다. 응용 프로그램 계층간에이 POCO 객체를 전달해야합니다. 따라서 MVC UI는 사용자 개체에 바인딩되며 컨트롤러가 전송되면 BL에서 일부 메서드를 호출하고 해당 사용자 개체에서 비즈니스 규칙 (암호가 유효 함)을 수행합니다. 이들을 실제 레이어간에 전달하려면 주 DAL에서 POCO를 추출하여 별도의 어셈블리에 배치해야합니다. 이러한 개체는 일반적으로 도메인 개체라고하며 해당 방법론에 대한 자세한 정보를 얻으려면 Google 도메인 기반 개발을 수행 할 수 있습니다.

보안은 응용 프로그램 내에서 여러 가지 방법으로 구현 될 수 있습니다. 보안은 모두 다루고 자하는 항목의 깊이에 따라 다릅니다. MVC에서 가장 기본적인 것은 컨트롤러 클래스 (Google : 컨트롤러 작업 보안)에서 Authorize 속성을 사용하는 것입니다.사용자가 인증되면 그들은 응용 프로그램 역할의 몇 가지 유형을 할당 할 수 있으며 사용자가 다음과 같은 형식으로 사용하여 이러한 역할 중 하나가 있는지 확인할 수 있습니다 : 나는 당신의 POCO를 전달하는 데 반드시 필요한 것은 아니라고 생각

[Authorize(Roles = "ModifyUserRoles")] 
     public ActionResult About() 
     { 
} 

Answer 2

사용자의 컨텍스트는 사용자 개체를 반환하는 경우, 선택 암호 "확인"것 :

public User GetUser(string login, string password) 
{ 
//...code to set up context var... 
var user = (from o in context.Users.OfType<User>() where o.UserID == login && o.Password == password) select o).FirstOrDefault(); 
//...maybe more code... 
} 

그것은 (암호를 암호화하는 방법과 실패한 로그인을 처리하는 방법을 귀하의 비즈니스 계층까지되어야한다 메서드는 null을 반환합니다.

개인적으로 비즈니스 로직이 DAL에 있어야한다고 생각하지 않습니다. 비즈니스 계층에서 가장 잘 수행되는 기능에 액세스 할 수있는 사용자를 결정하지만 지연로드를 비활성화하고 사용자 기반의 탐색 속성 만 포함 시키거나 필요할 때 해당 속성에 대한 추가 요청을 할 수 있습니다. 성능상의 이유로 반환되는 데이터의 양과 유형이 그 결정을 이끌 것입니다.

Answer 3

을 예를 들어 상황에 따라 View 레이어는 사용자 이름 및 비밀번호 속성 만있는 간단한 View Model을 필요로하며 BL로 전달합니다. BL은 리포지토리를 통해 User 도메인 객체를 가져 오는 BL입니다. View 레이어에서받은 것과 대조하여 비밀번호를 검증하십시오.