3
내가 일하는 회사는 거의 전적으로 저장 프로 시저를 기반으로하는 대형 응용 프로그램을 개발합니다.저장 프로 시저 비즈니스 논리와 ORM을 섞음
우리는 고전적인 ASP 및 SQL Server를 사용하며 비즈니스 논리의 주요 부분은 이러한 저장 프로 시저 안에 포함되어 있습니다.
예를 들어, 하나의 저장 프로 시저를 다른 목적 (삽입, 업데이트, 삭제, 일부 계산 ...)으로 사용할 수 있습니다. 대부분의 경우 저장 프로 시저가 관련 테이블의 작업에 사용되지만 항상 그런 것은 아닙니다.
가까운 미래에 ASP.NET (WebForms)으로 이동할 계획입니다.
저는 데이터베이스 외부에서 비즈니스 로직을 이동하도록 권장하는 많은 게시물을 StackOverflow에서 읽었습니다. 것은 우리 회사에서 결정을 내리는 사람들을 설득하려고 시도한 것이며 나는 마음을 바꾸기 위해 할 수있는 것이 아무것도 없다..
저는 객체 지향 프로그래밍의 장점을 사용할 수 있기를 원하기 때문에 테이블을 실제 클래스에 매핑하려고합니다. 지금까지의 해결책은 ORM (Entity Framework 4 또는 nHibernate)을 사용하여 개체를 수동으로 매핑하지 않고 대부분 데이터를 검색하는 것입니다. 및 데이터 액세스 계층을 사용하여 저장하기 위해 기존 저장 프로 시저를 호출합니다. .
나는 이것에 당신의 충고를 원합니다. 좋은 해결책이라고 생각하십니까? 어떤 아이디어?
편집 : 표준 DataTable/DataRow 방식으로 진행해야합니까?
여전히 ORM을 통해 procs를 호출 할 수 있습니다. – ScottE
@ScottE : 알아요,하지만 내 sp의 매개 변수가 클래스 멤버에 매핑되지 않은 경우 제대로 작동합니까? 이상한 연결 문자열 프로세스를 사용하여 sp (예 : "^ custid = 123^custname = blabla^adress = 1000 1st avenue")에 하나의 매개 변수 만 전달한 다음 SP에서 구문 분석합니다. – Jason
어, 이상한! – ScottE