웹 서비스의 데이터 변환에서 비효율적 인 것으로 나타남

Question

저는 약 1 년 동안 웹 서비스를 작성해 왔으며 데이터베이스에서 데이터를 가져 와서 사용자에게 표시하고 다시 사용하는 프로세스가 비효율적이라고 생각됩니다 .

이 질문의 목적은 내가 모범 사례를 다음과 그냥 추가 작업을 추가하지하고 있는지 확인하는 것입니다. 여기에

는 최종 사용자와 백업하려면 DB에서 데이터에 대한 경로입니다.

1. 서비스는 데이터 액세스 계층 (DAL) 객체로 데이터베이스에서 가져옵니다.
2. 서비스 DataContract로 변환하여 클라이언트에 보냅니다.
3. 클라이언트는 DataContract를 얻고/객체가
4. 클라이언트가 DataContact에 클라이언트 측 객체를 변환
추가
5. 클라이언트/사용자가 변경을 수행 객체를 표시하는 클라이언트 측 객체로 변환하고 서비스
로 전송
6. 서비스는 DataContract를 받아서 데이터 액세스 계층 개체로 변환합니다.
7. 서비스는 데이터베이스를 변경/새 오브젝트로 업데이트합니다.

개체를 추적하는 경우 개체가 4 번 변환됩니다 (DAL-> 계약 -> 클라이언트 개체 -> 계약 -> DAL). 앱이 데이터를 수평 확장하기 시작하면 많은 전환이 발생하는 것 같습니다.

이렇게하는 것이 최선의 방법입니까? 내가 놓친 게 있니?

중요한 경우 Visual Studio 2008, WCF, LinqToSQL 및 Windows Mobile 5.0 (NETCF)을 사용하고 있습니다.

Answer 1

전환 수를 줄이면 (즉, 레이어를보다 단단히 연결하는 경우) 발생하는 문제가 누락되었을 수 있습니다.

서비스에서 직접 DAL 개체를 반환 할 수 있습니다. 문제는 DAL 개체가 DAL 개체라는 사실에 관한 데이터를 포함 할 가능성이 있으며 데이터가 전달하는 데이터가 아니라는 점입니다. 예를 들어 LINQ to SQL 클래스는 LINQ to SQL 기능을 포함하는 기본 클래스에서 파생됩니다.이 기본 클래스 데이터는 클라이언트에서 필요하지 않으므로 보내지 않아야합니다.

클라이언트는 서버에서 보낸 DAL 개체를 직접 사용할 수 있습니다. 하지만이를 위해서는 클라이언트와 서버가 동일한 플랫폼 인 .NET을 사용해야합니다. 또한 클라이언트가 서버 측 DAL 개체를 사용할 수 있도록 호환 가능한 버전의 .NET을 사용해야합니다.

클라이언트는 이제 INotifyPropertyChanged와 같은 클라이언트 측 인터페이스가 필요 없다고 가정하면 DAL 개체를 표시 할 수 있지만 서버는 실행하는 데 이러한 코드가 필요하지 않지만 클라이언트는 데이터 바인딩 및 확인.

각 레이어는 자체 요구 사항을 충족합니다. 이러한 요구 사항을 독립적으로 유지함으로써 코드를 쉽게 디자인하고 유지 관리 할 수 ​​있습니다. 예, 데이터를 복사해야하지만, 동시에 4 가지 작업을 수행해야하는 코드를 유지 관리하는 데 드는 비용과 비교하면 저렴합니다.