웹 페이지가 아닌 다른 프로젝트에서 System.Web을 추가하는 것이 나쁜 습관입니까?

저는 회사의 웹 프로젝트 아키타 입을 만들고 있습니다. 아이디어는 이미 필요한 모든 작업, 보안, IoC, 로깅 등을 사용하여 새 프로젝트를 시작하기위한 템플릿과 같은 것입니다 ...웹 페이지가 아닌 다른 프로젝트에서 System.Web을 추가하는 것이 나쁜 습관입니까?

템플릿의 보안 측면에서 일하고 있습니다. 그리고 처음에는 맞춤 보안 공급자를 만들고 싶었지만 Microsoft가 이미 Membership을 통해이를 수행했음을 깨달았습니다 ... 어떤 프로젝트라도 공급자 ... 그들은 단지 web.config를 변경할 필요가 있고 그게 다야 ...

하지만 내 문제는 ... 다른 계층이 사용자 정보를 얻을 수 있기를 바란다면 .. . 서비스 계층 (비즈니스 서비스 ... 웹 서비스가 아닌)과 마찬가지로, System.Web 및 System.Web.ApplicationServices를 해당 클래스 라이브러리에 추가합니다.

나쁜 습관입니까? 휠을 다시 발명하고 싶지 않고 Microsoft 멤버십 모델만으로도 충분합니다.

감사합니다.

출처

2012-09-11 varholl

사실은 System.Web가 ASP.NET의 일부라는 것이다. System.Web의 많은 메소드는 HttpContext.Current (예 : 현재 HTTP 요청에 대한 컨텍스트)를 사용합니다. 비 ASP .NET 응용 프로그램에서 System.Web을 사용하면 HttpContext를 사용할 수있는 메서드를 사용하여 클래스에 액세스 할 수 있기 때문에 이상한 방식으로 실패 할 위험이 있습니다. 이것은 나쁜 생각입니다. 그래서, 또한 나쁜 관행으로 간주되어야합니다.

의도는 System.Web의입니다. 예, 그냥 어셈블리 일 뿐이므로 IDE를 사용하면 원하는 어셈블리를 거의 참조 할 수 있습니다. 그러나 System.Web의 의도는 ASP.NET 응용 프로그램의 컨텍스트에 있어야합니다. 이것이 바로 Microsoft의 개발자들이 생각하는 것입니다. 그래서, 그들은 그 가정하에 그것을 진화시킬 것입니다. 앞으로는 ASP.NET 응용 프로그램에 도움이되는 변경 사항으로 인해 응용 프로그램을 효과적으로 중단시킬 수 있습니다.그렇게되면 응용 프로그램의이 부분을 디자인 (또는 재 설계) 할 계획이 아니라 응용 프로그램을 재 설계 할 필요가 없습니다.

출처

2012-09-11 14:17:13 exacerbatedexpert

필자는 프런트 엔드 프로젝트와 비즈니스 계층 모두에서 투명하게 인증 멤버쉽 공급자를 공개 할 수있는 방법을 알고 있습니까? 예를 들어 ... 어떤 경우에 사용자 역할에 따라 일부 방법을 허용하거나 거부하려고 할 수 있습니다 ... 컨트롤러에서 권한 부여를 통한 인증으로는 충분하지 않습니다. – varholl

비즈니스 계층이 데이터 원본과 관련이 없으므로 비즈니스 계층에서이를 사용하는 것이 바람직하지 않을 수 있습니다.

데이터 요청을 웹 레이어로 보내고 수집 된 데이터를 비즈니스 계층 또는 필요한 경우 별도의 인증 구성 요소에 노출하면됩니다.

엄격하게 비즈니스가 아닌 비즈니스 계층의 모든 요소는 정의 된 인터페이스가있는 클래스로 추상화해야합니다.

출처

2012-09-11 13:31:56 PhonicUK

'System.Web.Mail' (pre .NET 2.0)은 어떻습니까? BL이 사용자의 UI가 아닌 이메일을 보내길 원할 것입니다. – Laoujin

다시 비즈니스 계층은 구현에만 국한되지 않아야하므로 표준 인터페이스를 사용하여 다른 클래스로 추상화 할 수 있습니다. 내 대답이 업데이트되었습니다. – PhonicUK

System.Web은 다른 라이브러리와 마찬가지입니다. 예, 많은 코드가 포함되어 있으며 컴팩트 프레임 워크에 포함되어 있지 않으며 일부 기능이 복제되지 않습니다. 예를 들어 WebUtility은 .Net 4.5의 새로운 기능이며 HttpUtility의 많은 기능을 수행합니다. 그러나 클래스 라이브러리 일뿐입니다.

출처

2012-09-11 13:37:33 akton

@exacerbatedexpert 나는 그 진술이 일반화라고 생각하기 때문에 모든 상황에 맞지는 않습니다. 비즈니스 계층이 웹 문제를 다루는 경우, 예를 들어 좋은 선택 일 수 있습니다. – akton

-1

전혀 나쁘지 않다고 생각합니다. System.Web은 .NET Framework의 일부이므로 .NET을 사용할 수있는 모든 곳에서 사용할 수 있습니다. html 및 URL 처리 작업이 필요할 때 System.Web을 비 웹 응용 프로그램에서 사용합니다.

출처

2012-09-11 13:42:49 Alexander

System.Web이 .NET Framework 클라이언트 프로필의 일부가 아니기 때문에 문제가 발생할 수 있습니다. 이를 참조하려면 소비자가 전체 프레임 워크 패키지를 설치해야합니다. 서버 응용 프로그램을 작성하는 경우에는 문제가되지 않습니다.

참조 : Assemblies in the .NET Framework Client Profile

출처

2012-09-11 13:53:30 sisve

.NET Framework Client Profile은 .NET 4.5부터는 중단되었습니다. –

System.Web은 프런트 엔드에만 있어야합니다. 아키텍처의 모든 부분이 아닙니다. 가장 좋은 예는 Asp.Net 5에서 어떤 일이 일어나고 있는지, 제거하는 것입니다. 웹 구성 요소를 프런트 엔드 계층에 격리 시키면 아키텍처의 모든 계층을 수정하지 않아도됩니다. 중간 (비즈니스 로직, 변환 로직 등) 및 백엔드 (데이터베이스, Entity Framework, 웹 API 호출)에서 항상 프론트 (웹, 웹 API, signalR 등)를 분리해야합니다.

출처

2015-01-12 16:27:53

웹 페이지가 아닌 다른 프로젝트에서 System.Web을 추가하는 것이 나쁜 습관입니까?

답변

관련 문제