그것이 있었던 방식
몇 년 동안 저는 다음과 같은 소프트웨어 솔루션을 조직했습니다.
- 데이터 액세스 비즈니스를 추상화하기위한 DAL (Data Access Layer)
- 비즈니스 규칙을 데이터 세트에 적용하고 인증을 처리하는 BLL (Business Logic Layer)
- 유틸리티 (Util)는 시간이 지남에 따라 구축 한 일반적인 유틸리티 메소드의 라이브러리 일뿐입니다.
- 물론 웹, 데스크탑, 모바일 등 모든 것이 가능합니다.
지금의 방식
지난 4 년 동안 나는 Microsoft의 Entity Framework (주로 .NET 개발자)를 사용 해 왔으며 Entity Framework가 이미 내 DAL이했던 일 : 데이터베이스에 대해 CRUD를 실행하는 사업을 추상화합니다.
따라서 일반적으로 다음과 같은 메소드 모음이있는 DAL로 끝납니다.
public static IQueryable<SomeObject> GetObjects(){
var db = new myDatabaseContext();
return db.SomeObjectTable;
}
그런 다음 BLL에서이 방법은 다음과 같이 사용됩니다.
public static List<SomeObject> GetMyObjects(int myId){
return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}
이것은 물론 BLL이 일반적으로 몇 줄의 로직을 더 적용하기 때문에 간단한 예이지만, 그러한 제한된 범위에 대해 DAL을 유지하는 것은 약간 과도하게 보입니다.
DAL을 포기하고 BLL 방법을 다음과 같이 작성하는 것이 낫지 않습니까?
public static List<SomeObject> GetMyObjects(int myId){
var db = new myDatabaseContext();
return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}
위에서 언급 한 이유로 향후 프로젝트에서 DAL을 삭제하는 것을 고려하고 있지만 그렇게하기 전에 프로젝트를 진행하기 전에 여기에서 커뮤니티를 여론 / 예언 / 의견을 위해 여론 조사를하고 싶습니다. 기대하지 마십시오.
모든 의견을 부탁드립니다.
최신 정보
합의는 별도의 DAL이 필요하지 않은 것으로 보이지만 (여기서 내 자신의 추론을 만드는 것)은 공급 업체의 잠금을 피하는 것이 좋습니다. 예를 들어, 위 그림과 같이 EF 통화를 추상화하는 DAL이있는 경우 BLL을 다시 작성할 필요가없는 다른 공급 업체로 전환하십시오. DAL의 기본 쿼리 만 다시 작성하면됩니다. 그렇게 말하면서, 나는 이것이 일어날 시나리오를 구상하기가 어렵다는 것을 알게되었습니다. 이미 Oracle db의 EF 모델을 만들 수 있습니다 .MSSQL이 제공됩니다 .MySql도 가능하다는 것을 확신합니다 (??). 그래서 여분의 코드가 가치있는 ROI를 부여하는지 확실하지 않습니다.
GetMyObjects(int myId)의 날조 / 스텁 / 조롱하는 것보다 쉽습니다을 GetObjects.Where(ob => op.accountId == myId).ToList().