웹 기반 응용 프로그램을 개발할 때 고려해야 할 사항은 무엇입니까

Question

내부 고객 용 응용 프로그램을 개발하고 있습니다. 요구 사항 중 하나는 잠재적으로 다른 조직에 판매 될 수있는 방식으로 개발된다는 것입니다. 신청서는 기부자, 기부자, 참가자 및 행사를 관리하는 기금 모금 기관 추적 프로그램입니다. 필자는 인증을위한 플러그인 아키텍처 (내부적으로 권한 부여가 처리됨)를 개발하고 외부 디렉토리에서 인구 통계 데이터를 추출해야 할 필요가 있음을 이미 알고 있습니다.

응용 프로그램은 ASP.NET/C#/Linq/SQL Server에서 작성됩니다. 이 시점에서 나는 대체 데이터베이스를 지원할 수는 없지만, 필요한 경우 다른 Linq 드라이버를 통해이 작업을 수행 할 수 있다고 생각합니다.

지금까지 작성한 모든 웹 응용 프로그램은 사용자 정의 구현이므로 플러그인 및/또는 구성 항목을 통해 해결해야 할 다른 사항이 있는지 알고 싶습니다. 모든 입력이 도움이 될 것입니다.

감사합니다.

Answer 1

"모든 것을 할 수 있도록"프레임 워크를 만들지 않으려 고 조심하고 싶습니다. 이것은 많은 개발자들이 처음 몇 개의 대중 시장 소프트웨어 앱을 만들 때 자주 범하는 실수입니다.

고객이 이미 있으며 초기 버전의 응용 프로그램을 은행 송금 한 것으로 보입니다. 고객이 대량으로 시장에 대해 생각하기 전에 가능한 한 빨리 고객이 필요로하는 것을 많이 제공해야합니다.

자신에게 유리하게이 응용 프로그램을 사용하거나 구매할 유일한 고객이 될 것으로 기대하십시오. 과거에는 다른 맞춤 앱을 디자인했을 때와 똑같은 방식으로 애플리케이션을 디자인하십시오.

나중에 다른 고객에게 확장하기 위해해야 ​​할 일은 asp.net의 기능 및 기능을 가능한 한 많이 사용하고 가능한 한 간단하고 가볍게 유지하고 많은 " 고급 "기능을 버전 1.x에서 제거 할 수 있습니다.

1x는 귀하의 증명 근거가 될 것입니다. 초기 고객이 필요로하는 작업을 수행하는 응용 프로그램을 제공하고 잘 수행하는지 확인하십시오.

성공한 경우 1.x가 초기 고객의 요구 사항 대부분을 실제로 충족 시키면 모든 고객의 요구 사항 대부분을 충족시키는 응용 프로그램을 보유하고 있음을 알게됩니다. 축하해, 당신은 이미 상용 시장 신청이 가능한 대부분의 길을 가고 있습니다!조심하는

것들 :

1. 당신은 정말 여러 데이터베이스 플랫폼을 지원해야합니까? 물론 SQL 서버에 "선호하는" "고객"이있을 수 있습니다. 오라클, MySQL, VistaDB, SQL Server 등을 지원할 수있는 마법의 DAL을 작성하고 시험해보고 싶은 유혹을받을 것입니다. 설정 옵션을 변경하거나 설치 프로그램에서 올바른 선택을하면됩니다. 그러나 사실 이런 종류의 "플랫폼"중립성은 디자인에 엄청난 복잡성을 추가하고 어떤 기능을 활용할 것인지에 심각한 제한을 부과합니다. 공급자 디자인 패턴과 같은 것들은 당신을 이런 종류의 디자인이 그렇게 어렵지 않다는 생각으로 속일지도 모릅니다. 그러나 당신은 틀릴 것입니다. 실용 주의적이어야하고 잠재 시장의 90 %가 수용 될 수 있도록 신청서를 디자인하십시오. 특히 데이터 액세스를 사용하면 일반적으로 ASP.NET 응용 프로그램을 설치하고 실행하려는 시장의 90 % 이상이 SQLExpress 또는 SQL Server를 사용할 수 있고 기꺼이 사용할 수 있습니다. 대부분의 경우 여러 데이터베이스를 지원하는 추가 판매에서 얻을 수있는 것보다 훨씬 많은 돈과 시간을 절약 할 수 있습니다.

2. "모든 것"을 온라인 관리 도구를 통해 구성하지 않도록하십시오. 예를 들어, 응용 프로그램의 모든 텍스트를 관리 도구로 구성 할 수 있습니다. 그것은 훌륭하지만 비용도 많이 듭니다. 개발하는 데 시간이 오래 걸리며, 그렇지 않으면 필요하지 않은 관리 도구가 포함되도록 응용 프로그램의 범위를 늘려야하며 응용 프로그램을 고객의 90 %가 사용하기가 더 복잡하고 어렵게 만듭니다 기본 텍스트는 신경 쓰지 않아도됩니다.

3. 현지화를 신중하게 고려하십시오. 당신이 하나의 언어에 큰 국제 시장을 고수 할 것이라고 생각하지 않는다면. 로컬 리 제이션은 너무 어렵지는 않지만 코드의 모든 측면을 복잡하게 만듭니다 ... 그리고 이는 모든 크기의 응용 프로그램에 많은 요소를 추가합니다. 나의 엄지 손가락 규칙은 나의 처음 시장의 언어만을 목표로 삼는 것이다. 응용 프로그램이 다른 시장에 관심이 있다면 버전 1.0에서 현금을 회수하고 응용 프로그램이 처음부터 실행 가능한 시장임을 증명 한 후에 버전 2.x에서 현지화를 수행합니다. 그러나 둘 이상의 언어 나 문화에 익숙하다면 처음부터 현지화를 지원하십시오.

4. 버전 1.0의 경우 드롭 인 모듈 또는 고급 서비스 API에 대해 걱정하지 마십시오. 재사용 가능한 프레임 워크에서 이미 많은 경험이 있다면 버전 1.0에서이 기능을 사용할 수 있지만 이러한 종류의 아키텍처에 대한 경험이 부족하다면 버전 1.x에서는 이러한 기능에 너무 많은 시간을 낭비하게되고 가능성이 여전히 잘못 받고 어쨌든 버전 2.x에서 다시 건축해야합니다.

5. 정말 좋은보고 기능이 있는지 확인하십시오. 당신이 말하는 응용 프로그램의 종류에 대해, 이것은 심지어 응용 프로그램이 시장을 가지고 있는지 결정하는 것입니다. 화면에서 정렬/필터링 만하는 것이 아니라 인쇄 할 수있는 예쁜 보고서가 필요합니다. 이 돈과 시간을 문 밖으로 밀어 넣으십시오.

Answer 2

가장 중요한 것은 하드 코딩되거나 삽입 된 클라이언트 특정 정보가 전혀없는 일반적인 방식으로 디자인하는 것입니다.

모든 클라이언트 관련 정보는 메타 데이터를 통해 구성 할 수 있어야합니다. 당신이하는 일은 완전히 당신에게 달려 있지만, 주요 방법은 XML, 데이터베이스 또는 속성 파일을 이용하는 것입니다.

이렇게하면 각자 자신의 구성 파일이나 데이터를 가질 클라이언트 수에 관계없이 판매 될 수 있습니다.

Answer 3

Abarax는 훌륭한 답변을주었습니다. 음성 언어 (영어, 프랑스어, 독일어 등)와 조직의 언어 모두에 대해 현지화를 고려해야한다고 강조했습니다. 일부 장소는 작업 표, 서류 정리 또는 작업 주문이라고 부를 수 있으며, 모든 항목이 항상 무언가라고 부르는 항목과 일치하지 않으면 각자가 우는 소리를 내며 우는 소리를냅니다.

Answer 4

오픈 소스 기술을 사용하는 경우 모든 라이센스 정보를 한 곳에서 관리하는 데 약간의 시간을 투자하십시오.