티스토리 툴바


직장인이라면 이유가 무엇이 됐든 누구나 한 번쯤은 사표를 쓰는 것을 고민한다. 그렇다고 내키는 대로 사표를 던질 수는 없는 일. 객관적으로 자신의 상황을 파악하는 것이 필요하다.

 

美 씨넷은 IT 업계 종사자가 회사를 떠나고 싶어 하는 10가지 이유에 대해 보도했다. IT 업계인이 사표를 쓰고 싶을 때 한 번쯤 참고하는데 유용하다. 만약 10가지 항목 모두에 해당한다면 자신의 정신 건강을 위해 다른 직종을 찾아보는 것도 한 가지 방법이다.

 

■스트레스  

 

스트레스는 직장이라면 어디나 있다. 그럼에도 씨넷은 “IT 분야의 스트레스는 타 직종보다 심하다”고 단언했다. 고객이나 사용자가 회사에 전화를 걸어올 때는 거의 대부분 즉시 해결해야하는 비상사태가 발생했기 때문이라는 설명이다. 예컨대 오류(버그) 발생, 보안사고 등이 그렇다.

 

때문에 IT 업종의 경우 실수가 허용되지 않는 경우가 많다. 일반적으로 고객은 자신들이 사용하는 IT서비스가 완벽하게 작동하기를 바라기 때문이다. 장애 발생시 심하면 고객사와의 계약을 연장할 수 없거나 담당자가 일자리를 잃게 될 수도 있다.

 

씨넷은 “IT 업종에서 스트레스는 끊이지 않는다”며 “우리는 항상 더 열심히 일할 수밖에 없다”고 말했다.

 

■근무시간  

 

출근은 월요일부터 금요일까지, 근무는 하루 8시간만 하고 싶다고? 씨넷은 과감하게 “다른 업종을 찾아봐라”고 조언한다. IT분야는 거의 연중무휴나 다름없다는 것이 그 이유다. 웹사이트가 하루 24시간, 1년 365일 서비스 되는 것을 생각하면 된다.

 

직장에서의 근무 시간 뿐만이 아니다. 겨우 퇴근을 하고 난 후에도 끊임없이 자기 자신을 갈고 닦아야 한다. 눈이 돌아갈 정도로 빠르게 변하는 IT 트렌드, 기술 등을 따라잡으려면 자기계발은 필수다.

 

■임금체불  

 

사실 임금체불은 직장인의 가장 큰 스트레스 요소다. 정기적으로 들어오는 수입이 없다면 생활 자체가 안정적이지 못할 수밖에 없다. 실제로 우리나라에서도 임금체불로 인한 사회 문제가 발생하고 있다. 국내서도 개인이 회사를 상대로 체불된 임금을 받으려면 노동부에 신고해야 하는 등 절차가 복잡하다.

 

씨넷은 IT업종의 경우 영세한 규모의 개발사가 많기 때문에 임금체불이 일어나기 쉽다고 분석했다.

 

■대인관계  

 

씨넷은 IT업종 종사자들에 대해 “구세주와 죄인이 한 몸에 있는 사람들”이라고 설명했다. 다소 자조적이지만 IT 분야 대인관계의 어려움을 잘 나타낸 표현이다.

 

잭 월렌 IT컨설턴트는 “IT 컨설팅 업무를 시작하기 전, 나 자신은 적극적이고 명랑한 사람이었다”며 “IT분야에 몸을 담고 난 후에는 나 자신도 놀랄 만큼 변했다”고 말했다.

 

월렌은 “IT 업종의 모든 사람이 악당이라고 주장하는 것은 아니다”면서도 “IT에서는 신속성, 변화, 위험성 등 업종 특성상 인간의 다양한 양상을 볼 수 있다”고 덧붙였다.

 

■명령계통  

 

다섯 번째 이유는 직장 상사다. 사실 아무리 IT관련 회사라도 사장이나 고위 임원이 IT전문가인 경우는 많지 않다. 때문에 종종 실무진들의 의견과 반대되는 의사결정을 내릴 때가 있다.

 

씨넷은 특히 개발자 등 실무진이 사용하는 PC를 10년 이상 쓸 수 있다고 생각하는 상사가 많다는 것을 꼬집었다. 결국 상사가 IT 직무와 기술에 대한 이해가 없다면 업무 자체가 아예 불가능해지거나 아주 어려워진다.

 

■테크놀로지  

 

잭 월렌은 “기술 관련 문제 때문에 직장을 때려치우고 싶다는 생각을 하는 사람들은 주로 윈도우 사용자”라고 주장했다.

 

자신이 IT컨설턴트 일을 할 때 상담해온 사람 대부분이 윈도우 시스템을 제대로 작동하게 만드는데 상당히 애를 먹고 있었다는 설명이다. 매일매일 시스템 유지와 보수에 성공할 수도, 혹은 실패할 수도 있지만 확실한 것은 그만큼 업무가 늘어난다는 점이다.

 

■경쟁  

 

직장인이 명심해야 할 것 중 하나는 자신보다 뛰어난 인재가 있다는 사실을 인식하는 것이다. 씨넷은 “특히 IT 분야에서는 더하다”고 지적했다.

 

일반 직장에서의 경쟁이 1:1로 이뤄진다고 가정하자. 반면 IT업종에서는 자신보다 일이 빠르고 좋은 장비를 가진 전문가들이 전 세계에 적게는 수백명에서 많게는 수천명까지 있을 수 있다.

 

빌 게이츠가 “나의 경쟁자는 학교를 중퇴하고 차고에서 컴퓨터를 뚝딱거리는 젊은이들이다”라고 말한 것도 같은 맥락이다. IT 분야는 항상 변화하기 때문에 트렌드를 놓치거나 최신 기술을 익히지 못하면 고용되지 못하거나 일자리를 잃을 가능성이 있다.

 

씨넷은 “IT 업계의 경쟁은 매일 치열해지고 있으며, 그 강도는 엄청난 것”이라고 평했다.

 

■클라우드  

 

최근 ‘클라우드’라는 용어가 남용되고 있다. 씨넷은 일부 고객사와 최종 이용자들이 클라우드가 업무를 더 쉽게, 더 좋게, 더 빨리 이뤄줄 것이라는 환상을 가지게 되는 것을 경계해야 한다고 지적했다.

 

씨넷은 “클라우드는 IT 분야 중에서도 정의가 유동적이며, 앞으로도 계속해서 변화할 것으로 예측되는 분야”라며 “그럼에도 업계에서는 클라우드는 안전하냐, 비용이 얼마나 드냐 등 성급한 질문이 쏟아지고 있다”고 말했다.

 

잭 월렌 역시 “내가 클라우드에 대한 질문을 받으면 고객에게 구글 문서 도구를 사용한 적이 있는지 묻는다”며 “만약 ‘예’라고 대답한다면 이미 클라우드를 사용하고 있다고 답한다”고 말했다.

 

■표준의 부재  

 

일반적으로 적용할 수 있는 기술스 표준이 있으면 IT 업무는 다소 편해진다. 그러나 실상은 기업별로 자체 소프트웨어를 사용하기 때문에 호환이 쉽지 않다.
씨넷은 자체 소프트웨어를 제작하는 회사들이 코드를 비공개로 유지하고 표준과 호환되지 않도록 유지해 최대한 수익을 내려고 한다고 꼬집었다. 결국 이들이 표준을 따르지 않을 경우 최종 사용자나 협력사 등은 불편해질 수밖에 없다.

 

최근에는 오픈소스 프로젝트를 지향하고 있는 추세지만 아직까지는 부족하다는 것이 업계의 평이다.

 

■존중  

 

대부분 일반인은 IT 전문가들에 대해 편견을 가지고 있다. 자신들이 과거에 IT 전문가들에게 당해왔다고 생각하기 때문이다.

 

씨넷은 “과거 IT 전문가들은 고객에게 상품을 팔기 위해서 다소 막무가내인 수단도 서슴치 않았다”며 “이런 악순환이 반복되면서 IT 종사자들은 존경을 받기 어려운 상황에 처한 것”이라고 분석했다.

 

아울러 엔지니어에 대한 낮은 대우 등도 IT종사자들이 이직하고 싶게 만드는 요인이라고 덧붙였다.
Posted by I.DEA
원문 :  http://news.nate.com/view/20101012n00285?mid=n0308

[중앙일보 이나리] 국내 스마트폰 사용자가 400만 명에 육박하면서 이들을 노린 각종 사업 모델이 국내에서도 속속 선보이고 있다. 가장 활발한 것이 소셜 커머스다. 소셜네트워크 서비스(SNS)와 위치기반서비스(LBS)를 접목한 공동구매 방식이다. 현재 국내 소셜 커머스 업체 중 규모가 가장 큰 회사는 ‘티켓몬스터’다. 지난 5월 문 연 이 회사 회원은 5만5000여 명이다. 매일 30만 명 이상이 사이트를 찾는다. 10만원짜리 ‘오페라의 유령’ 입장권의 반값 쿠폰 1400장이 한 시간 만에 동나기도 했다.


<그래픽을 누르시면 크게 보실 수 있습니다>

포털업계도 소셜 커머스 시장에 속속 뛰어들고 있다. SK커뮤니케이션즈는 국내 최대 SNS인 싸이월드 2500만 회원, 11억 건에 육박하는 일촌 네트워크, ‘네이트온’ 메신저의 3200만 회원 등을 토대로 유·무선 소셜 커머스 시스템을 구축할 계획이다. 다음커뮤니케이션도 공동구매 플랫폼 형식으로 소셜 커머스 진출을 준비 중이다. 웹에 접속해 공동구매를 하고 이렇게 발행받은 쿠폰을 매장에서 쓰는 방식이다.

통신업계는 증강현실(AR)에 관심이 많다. SK텔레콤은 2월 휴대전화 카메라로 100만여 건물·상점 정보를 검색하는 ‘오브제’ 서비스를 선보였다. 또 한국관광공사와 함께 휴대전화 카메라를 이용, 실시간으로 다양한 관광정보를 보여주는 ‘스마트 투어’ 서비스도 내놓았다. KT는 AR를 통해 430만 건의 업체 정보를 검색하는 서비스를 제공한다.

QR코드는 스마트 커머스 관련 기술 중 현재 가장 활성화한 분야다. 신세계 이마트는 광고에 QR코드를 삽입해 스마트폰으로 이를 스캔하면 다양한 상품과 이벤트 정보를 볼 수 있도록 했다. GS샵 또한 쇼핑 카탈로그에 QR코드를 삽입해 정보를 제공한다. 인터파크는 웹사이트에 있는 QR코드를 스캔하면 스마트폰으로 할인 쿠폰을 보내주는 서비스를 시작했다.


<그래픽을 누르시면 크게 보실 수 있습니다>

다음커뮤니케이션의 김지현 모바일 본부장은 “어떤 기기든 사용자가 100만 명을 넘으면 패션이, 500만 명을 넘으면 트렌드가, 1000만 명을 넘어서면 문화(Culture)가 된다”고 말했다. 상거래를 하는 기업·개인이라면 지금이야말로 새 조류에 적극 대응할 시기라는 것이다. 미국 기업들 역시 스마트 커머스야말로 장기 불황을 끝낼 효과적 대안으로 기대한다.

☞이 용어들 알아두세요

증강현실(AR·Augmented Reality)
현실 세계에 실시간 부가정보를 담은 가상 세계를 합쳐 하나의 영상으로 만든 것. 휴대전화 카메라로 주변 거리·건물을 비추면 자동 검색된 상점·상품 정보가 화면에 나타나는 식이다. 바코드를 비추면 거기 담긴 상품 정보가 뜨기도 한다. 스마트폰 카메라로 거실을 비춘 뒤 가상의 가구 이미지를 끌어와 여기저기 배치해 보고 구매를 결정할 수도 있다. 의료·군사 분야 등에서는 가상체험·훈련도 가능하다.

QR코드(Quick Response code)
흑백 격자무늬 패턴에 정보를 기록하는 ‘2차원(2D) 바코드’의 일종. 기존 1차원 바코드가 20글자 내외의 정보를 담을 수 있는 반면, QR코드는 한글 1700자 또는 숫자 8000개 분량의 정보를 담는다. 1990년대 중반 일본 도요타자동차의 자회사인 ‘덴소웨이브’에서 물류 관리를 위해 개발했다. 라이선스 개방으로 누구든 무료로 사용할 수 있다.

소셜 커머스(Social Commerce)
SNS와 LBS를 활용한 온라인 상거래 모델로 특정 지역 네티즌들의 공동구매가 특징이다. 구매자 수가 일정 인원에 이르면 다양한 상품·서비스를 50% 이상 크게 할인된 가격에 살 수 있다. 소비자들이 공동구매자를 모으기 위해 SNS 등을 통해 입소문을 내는 과정에서 자연스레 상점·상품에 대한 홍보가 이루어진다.

위치기반서비스(LBS·Location Based Services)
이동통신사의 네트워크나 위성위치확인시스템(GPS) 등을 통해 얻은 위치 정보를 바탕으로 사용자에게 갖가지 정보를 제공하는 것을 말한다. 언제 어디서나 네트워크에 접속해 정보를 주고받는 ‘유비쿼터스’ 환경의 핵심이다.

스마트 페이먼트(Smart Payment)
스마트폰 사용자와 금융·통신·유통업체 간 정보 교환을 토대로 각종 개인화 서비스를 제공하는 것. 스마트폰 한 대로 여러 신용카드와 수십 개 멤버십 카드를 관리함은 물론, 휴대전화가 알아서 어떤카드·쿠폰·이벤트를 활용하는 것이 최선인지 자동 비교해 준다.

소셜 네트워크 서비스(SNS·Social Networking Service)
트위터·싸이월드 등 인터넷상에서 이용자들이 인적 네트워크를 형성할 수 있게 해주는 서비스다. 정보 공유와 의사소통을 하는 대표적 ‘1인 미디어’로 사회적 영향력이 갈수록 커지고 있다.

스마트 커머스(Smart Commerce)
스마트폰 등 컴퓨터 기능의 모바일 기기를 이용하는 모든 상거래를 뜻한다. 각종 첨단 정보통신기술(ICT)을 집약해 사용자의 현재 위치, 구매 패턴, 취향에 기반한 맞춤 정보를 실시간 제공한다. 상점의 위치, 상품 검색과 세부 정보, 가격 비교, 사용 후기 열람, 결제 등을 스마트폰 한 대로 일괄 처리한다.


Posted by I.DEA

LINQ to SQL을 이용하면 Data Access작업에서 (과거에 비해) 놀라울 정도의 생산성 향상을 가져옵니다. 하지만, 그만큼 성늠이 우수한가에 대한 의문을 가질 수 밖에 없는 것은 사실입니다. 하지만 몇 가지 Benchmark들을 확인하면, LINQ to SQL을 제대로 사용하면, ADO.NET SQL DataReader의 93%의 성능까지 낼 수 있다고 합니다.

따라서 여기에서는 LINQ to SQL을 이용하여 데이터를 조회하고 수정하는데 있어서 성능을 향상시킬 수 있는 10가지 중요한 Tunning Point를 정리해드립니다.

  1. DataContext의 ObjectTrackingEnabled 속성이 필요하지 않다면, Off로 설정하십시요.
    만약 당신이 데이터를 조회만 하고, 데이터를 수정하지 않는다면 DataTracking 기능은 필요치 않습니다. DataTracking는 Server Memory에 올려진 LINQ데이터의 변화를 추적하여 DataContext.SubmitChage()되는 순간 그 변화를 반영하는 기능을 합니다. 만약 데이터를 조회만 한다면 아래와 같이 사용하십시요.
    1.using (DataClassesDataContext db = new DataClassesDataContext())
    2.{
    3.     db.ObjectTrackingEnabled = false;
    4.}
  2. 전체 DB 개체들을 하나의 DataContext에 포함하지 마십시요.
    DataContext는 하나의 작업 단위를 표현해야지, 전체 DB를 표현해서는 안됩니다. 만약 당신의 DB개체 중에서 다른 개체와 연결되지 않고 독립적으로 동작하거나, 전혀 사용되지 않는 개체가 있다면, 그 개체들은 다른 DataContext로 분리하십시요. 만약 하나의 DataContext에 포함되어 있다면, 이러한 개체들은 DataContext를 선언할 때 불필요하게 메모리를 차지하며, DataConText의 CUD엔진이 사용하는 관리, 추적, 식별 비용을 증가시킬 뿐입니다.
    대신, 각 작업단위로 DataContext를 분리하는 것을 고려하십시요. 물론, Connection Pooling의 장점을 잃지 않기위해, 생성자를 이용하여 같은 Connection을 사용하도록 설정할 수 있습니다.
  3. 어디서든지 필요하다면 CompiledQuery를 이용하십시요.
    LINQ to SQL을 이용하여 표현식을 만들고 실행하기 위해서는 몇가지 단계가 존재합니다. 몇 가지 나열한다면 다음과 같습니다.
    1. Expression Tree의 생성
    2. Expression Tree를 SQL로 변환
    3. 생성된 SQL Query 실행
    4. 데이터 조회
    5. 조회된 데이터를 객체로 변환
    만약 당신이 같은 LINQ to SQL Query를 반복해서 사용한다고 할 때, 위의 과정 역시 반복된다고 한다면 그것은 불필요한 자원 낭비가 아닐 수 없습니다. 이 것이 바로 작은 System.Data.Linq 네임스페이스가 많은 자원을 소모하는 주 이유가 될 것입니다(같은 작업을 불필요하게 반복하는 것). CompiledQuery는 표현식을 Compile한 다음 이 것을 어딘가에 저장해둡니다. 그리고 같은 작업이 호출 되면 저장된 것을 통해 불필요한 Compile작업이 반복되는 것을 피하게 해줍니다. 이 기능은 정적 CompiledQuery.Compile메서드에 의해 실현할 수 있습니다. 예제는 다음과 같습니다.
    1./*
    2. 아래 NameSpance 선언 필요
    3. using System.Collections.Generic;
    4. using System.Data.Linq;
    5.*/
    6.Func<DataClassesDataContext, IEnumerable<People>> func =
    7.    CompiledQuery.Compile<DataClassesDataContext, IEnumerable<People>> ((DataClassesDataContext db) => db.Peoples.Where<People>(t => t.PeopleName == "손대관"));
    이 제 "func"는 Compiled Query로서 첫 실행시 단 한번만 Compile되게 됩니다. 다음 코드는 Compiled Query를 생성해서 Static Utility Class에 저장하는 예제입니다.
    01./*
    02. 아래 NameSpance 선언 필요
    03. using System.Collections.Generic;
    04. using System.Data.Linq;
    05.*/
    06.public static class QueriesUtility
    07.{
    08.    public static Func<DataClassesDataContext, IEnumerable<People>> GetActivePeoples
    09.     {
    10.        get
    11.        {
    12.            Func<DataClassesDataContext,IEnumerable<People>> func =
    13.                CompiledQuery.Compile<DataClassesDataContext, IEnumerable<People>> ((DataClassesDataContext db)
    14.                    => db.Peoples.Where<People>(t => t.ActiveCheck = false));
    15.            return func;
    16.        }
    17.    }
    18.}
    이 제 우리는 언제든지 위의 Compiled Query를 호출해서 사용할 수 있습니다.
    1.using (DataClassesDataContext db = new DataClassesDataContext())
    2.{
    3.    IEnumerable<People> p = QueriesUtility.GetActivePeoples(db);
    4.    lblTest.Text = p.Count().ToString();
    5.}
    이 렇게 저장하고 실행하는 것은 반복적인 호출 비용을 단 한 1번의 호출 비용으로 감소시켜줍니다. 위와 같은 Compiled Query를 많이 만들어 둔다고 성능이 저하되지 않는 가 걱정하실 필요도 없습니다. 모든 Compiled Query는 처음 실행 될 때 단 한번만 Compile됩니다.
  4. DataLoadOptions.AssociateWith를 사용하여 필요한 데이터만 조회하세요.
    우리는 Primary Key로 연결된 관련된 데이터들을 한번에 읽어들여야 할 때, Load 또는 LoadWith를 사용합니다. 하지만 대부분의 경우 추가적인 필터링을 하게 되는데요, 이 경우 DataLoadOption.AssociateWith라는 Geniric Method는 매우 유용합니다. 이 뿐만 아니라 데이터를 조회할 때 필요한 데이터만 조회하는 것은 성능향상을 위한 첫걸음 입니다.
  5. 필요하지 않다면 Optimistic Concurrency을 끄세요.
  6. DataContext에 의해서 생성되는 데이터 조회 Query를 지속적으로 확인하세요.
    데이터를 조회할 때, DataContext는 Query를 자동으로 생성하는데요, 실제로 사용되지 않는 불필요한 코드가 생성될 수 있습니다. 성능개선을 위해서는 생성되는 Query를 지속적으로 감시하고, 불필요한 코드가 생성되지 않도록 LINQ to SQL 표현식을 수정해야 할 것입니다. 우리는 DataContext의 Log 속성을 이용해서 생성된느 SQL문을 볼 수 있습니다.
    1.using (DataClassesDataContext db = new DataClassesDataContext())
    2.{
    3.    System.IO.StreamWriter httpResponseStreamWriter =
    4.        new StreamWriter(HttpContext.Current.Response.OutputStream);
    5.    db.Log = httpResponseStreamWriter;
    6.}
    위 코드는 생성된느 SQL문을 화면에 출력하는 코드입니다. Response개체 대신에 대상을 파일로 지정하는 것도 좋은 방법입니다.

    다른 방법은 'LINQ to SQL Debug Visualizer'를 사용하는 방법입니다. Debug 모드에서 손쉽게 생성된 SQL을 확인하고 실행할 수 있습니다. 'LINQ to SQL Debug Visualizer'에 대한 정보와 설치는 여기를 참조하세요.

  7. Attach()가 불필요한 Entity를 Context에 Attach하지 않도록 하세요
    조회된 Entity는 보통 DataContext에 연결되어 있으며, 내부적인 데이터 변화가 하나하나 추적되는 상태입니다. 이 상태에서는 Entity의 Update, Delete가 매우 쉽습니다. 하지만 Entity를 Serialize한 경우 처럼 DataContext와 Entity의 연결이 끊어진 상태도 존재합니다. 이럴 때 Attach를 통해 DataContext와 Entity를 연결하게 되는데, Entity를 Update 또는 Delete 할 경우에 Attach를 하는 것은 크게 문제가 되지 않습니다. 하지만 Update나 Delete하지 않음에도 Attach를 하는 경우가 있습니다. 이런 실수가 가장 많이 발생하는 경우가 바로 AttachAll()메서드로 Entity Collection을 DataContext로 연결하는 경우입니다.
    Object Tracking는 DataContext에 연결된 모든 개체의 Update, Delete를 추정하고 반영해주는 매우 멋진 기능이긴 하지만, 그만큼 많은 자원을 소모합니다. 따라서 위와 같이 Update, Delete가 되지 않는 Entity를 Attach하여 불필요하게 Entity가 추적되도록 하는 일은 최대한 피해야합니다.
  8. 불필요하게 Object Tracking가 작동하지 않는지 확인하세요
    다음과 같은 두 코드가 있을 때, 어느 쪽이 성능이 더 빠른지 생각해보라.
    예1)
    1.using (DataClassesDataContext db = new DataClassesDataContext())
    2.{
    3.    IQueryable<People> peopleList = db.Peoples
    4.        .Select(t => t);
    5.}
  9. 예2)
    01.using (DataClassesDataContext db = new DataClassesDataContext())
    02.{
    03.    var peopleList = db.Peoples
    04.        .Select(t => new
    05.        {
    06.            activeCheck = t.ActiveCheck,
    07.            deleteCheck = t.DeleteCheck
    08.        });
    09.}
    두 번째 표현식은 필요한 데이터를 걸러서 조회하고 있으며, 데이터 타입도 기존의 개체를 사용하는 것이 아닌 Var 타입을 사용하고 있기에, 첫번째 표현식이 더 빠를 것이라 생각할 수 있습니다. 하지만 실제로는 두번째 표현식이 더 자원을 적게 소모합니다. 첫 번째 표현식은 아직까지 Update, Delete 기능이 모두 지원하는 상태로 조회가 되므로 자원을 많이 소모합니다. 즉 첫번째 표현식은 Object Tracking가 동작하는 상태이며, 따라서 내부적으로는 데이터의 변화가 모두 일일이 추적되고 있는 상태입니다. 하지만 두번째 표현식 처럼 필요한 데이터를 걸러서 조회를 하게 되면, 조회된 List는 ReadOnly로 변하게 되며, 자연스럽게 보다 빠르게 동작합니다.
  10. 필요한 행만 걸러서 조회하세요.
    ListView에 데이터를 바인딩하고 Paging기능을 사용한다고 할 때, 우리는 Take와 Skip를 통해 필요한 페이지의 행만 조회할 수 있습니다. Skip, Take를 사용하지 않고 조회된 LINQ to SQL 결과를 바로 바인딩할 수 있지만, 그럴 경우 DB의 모든 데이터를 불러오기 때문에 행의 수에 비래하여 ListView의 속도도 느려집니다.
    아래는 해당페이지에 필요한 데이터만 조회하는 구문입니다.
    1.int intPageSize = 10;
    2.int intPageNum = 2;
    3.using (DataClassesDataContext context = new DataClassesDataContext())
    4.{
    5.    listView.DataSource = context.Peoples.Skip(intPageNum * intPageSize).Take(intPageSize);
    6.    listView.DataBind();
    7.}
  11. CompiledQuery를 오용하지 마세요.
    '어떻게 COmpiledQuery를 오용할 수 있는거지?'라는 생각을 하고 계신건 아닌지 모르겠네요. 여기서 하고자하는 말은 불필요한 최적화는 없어야 한다는 것입니다. CompiledQuery는 최소한 한번 이상 사용될 때에만 사용해야합니다.
    일반적인 LINQ to SQL 문장이 CompiledQuery 문장보다 더 빠릅니다. 왜냐하하면 CompiledQuery는 SQL Expression을 유지하고, 재사용하는 등의 모든 고려사항을 반영하기 위한 특별한 처리를 내부적으로 담고있기 때문입니다. 따라서 단순히 조회를 하는 일반적인 LINQ to SQL Expression 보다 무거울 수 밖에 없습니다.
Posted by I.DEA
TAG Linq
이전버튼 1 2 3 4 5 ... 25 이전버튼