Một số điều phổ biến cần xem xét khi phát triển một ứng dụng dựa trên web để được bán

Question

Tôi đang phát triển một ứng dụng cho một khách hàng nội bộ. Một trong những yêu cầu là nó được phát triển theo cách mà nó có khả năng có thể được bán cho các tổ chức khác. Ứng dụng này là một ứng dụng theo dõi cho một tổ chức gây quỹ sẽ quản lý đóng góp của họ, các nhà tài trợ, người tham gia, và các sự kiện. Tôi đã biết rằng tôi cần phát triển kiến ​​trúc plugin để xác thực (ủy quyền sẽ được xử lý nội bộ) và lấy dữ liệu nhân khẩu học từ một thư mục bên ngoài.

Ứng dụng sẽ được xây dựng trên ASP.NET/C#/Linq/SQL Server. Tại thời điểm này tôi không thực sự mở để hỗ trợ cơ sở dữ liệu thay thế, nhưng tôi nghĩ rằng tôi có thể làm điều này trong tương lai thông qua các trình điều khiển LINQ khác nhau, nếu cần thiết.

Tất cả các ứng dụng web mà tôi đã tạo cho đến nay đều là triển khai tùy chỉnh, vì vậy tôi muốn biết liệu có những thứ khác mà tôi cần phải giải quyết thông qua các plugin và/hoặc các mục cấu hình hay không. Bất kỳ đầu vào sẽ là hữu ích.

Cảm ơn.

Answer 1

Tôi muốn cảnh cáo bạn chống lại việc cố tạo khung làm "mọi thứ". Đây là một sai lầm phổ biến mà rất nhiều nhà phát triển thực hiện khi cố gắng xây dựng một số ứng dụng phần mềm thị trường đại chúng đầu tiên của họ.

Bạn đã có một khách hàng và họ có thể đang kiểm kê phiên bản đầu tiên của ứng dụng. Bạn cần phải cung cấp càng nhiều những gì khách hàng này cần nhanh như bạn có thể hoặc nó không thành công trước khi bạn thậm chí có thể suy nghĩ về thị trường đại chúng.

Tự làm ơn và mong rằng đây là khách hàng duy nhất EVER sẽ sử dụng hoặc mua ứng dụng. Thiết kế ứng dụng của bạn khá giống chính xác như bạn đã thiết kế bất kỳ ứng dụng tùy chỉnh nào khác của bạn trong quá khứ.

Tất cả những gì bạn cần làm để mở rộng quy mô cho khách hàng khác sau đó là gắn vào các tính năng và chức năng asp.net cổ phiếu càng nhiều càng tốt, giữ nó đơn giản và gọn gàng nhất có thể và cắt càng nhiều " các tính năng nâng cao "từ phiên bản 1.x khi bạn có thể thoát khỏi.

1.x sẽ là nền tảng chứng minh của bạn. Hãy chắc chắn rằng bạn cung cấp một ứng dụng thực hiện những gì khách hàng ban đầu của bạn cần nó để làm và nó làm nó vượt trội.

Nếu bạn thành công và 1.x thực sự đáp ứng hầu hết các yêu cầu ban đầu của khách hàng, bạn sẽ biết bạn cũng có một ứng dụng đáp ứng hầu hết các nhu cầu của bất kỳ khách hàng nào của bạn. Xin chúc mừng, bạn đã có hầu hết cách để có một ứng dụng thị trường thương mại khả thi!

Những điều cần xem ra cho:

1. Bạn có thực sự cần hỗ trợ nhiều nền tảng cơ sở dữ liệu? Chắc chắn, bạn có thể có một số khách hàng có thể "thích" MySql đến SQL Server. Bạn sẽ bị cám dỗ để thử và viết một số DAL ma thuật có thể hỗ trợ Oracle, MySQL, VistaDB, SQL Server, vv chỉ bằng cách thay đổi một số tùy chọn cấu hình hoặc thực hiện lựa chọn đúng trong trình cài đặt. Nhưng thực tế là loại nền tảng "trung lập" này thêm độ phức tạp lớn vào thiết kế của bạn và áp đặt những hạn chế nghiêm trọng về những tính năng bạn tận dụng. Những thứ như mẫu thiết kế của nhà cung cấp có thể đánh lừa bạn nghĩ rằng kiểu thiết kế này không quá khó ... nhưng bạn sẽ sai. Hãy thực dụng và thiết kế ứng dụng của bạn để có thể chấp nhận được 90% thị trường tiềm năng của bạn. Với truy cập dữ liệu nói riêng, nói chung 90% hoặc hơn về thị trường sẵn sàng cài đặt và chạy một ứng dụng ASP.NET cũng có khả năng và sẵn sàng sử dụng SQLExpress hoặc SQL Server. Trong hầu hết các trường hợp, bạn sẽ tiết kiệm được nhiều tiền và thời gian hơn bằng cách thiết kế cho máy chủ SQL chỉ hơn bao giờ hết bạn sẽ kiếm được từ việc hỗ trợ nhiều cơ sở dữ liệu.

2. Cố gắng tránh đặt "mọi thứ" có thể định cấu hình thông qua công cụ quản trị trực tuyến. Ví dụ, bạn sẽ bị cám dỗ để có TẤT CẢ văn bản trong ứng dụng được cấu hình bởi các công cụ quản trị. Đó là tuyệt vời, nhưng nó cũng là tốn kém. Cần nhiều thời gian hơn để phát triển, yêu cầu bạn tăng phạm vi ứng dụng của bạn để bao gồm cả một loạt các công cụ quản trị mà bạn không cần đến, và nó làm cho ứng dụng trở nên phức tạp và khó sử dụng hơn cho 90% khách hàng của bạn không quan tâm đến văn bản mặc định.

3. Cẩn thận xem xét bản địa hóa. Nếu bạn không nghĩ rằng bạn sẽ có một thị trường quốc tế lớn dính vào một ngôn ngữ. Bản địa hóa không quá khó, nhưng nó làm phức tạp mọi khía cạnh của mã của bạn một chút ... và điều đó làm tăng thêm rất nhiều trong bất kỳ ứng dụng nào có kích thước nào cả. Quy tắc chung của tôi là chỉ nhắm mục tiêu ngôn ngữ của thị trường ban đầu của tôi. Nếu ứng dụng có sở thích ở các thị trường khác thì tôi quay lại và thực hiện bản địa hóa trong phiên bản 2.x sau khi tôi lấy lại tiền từ phiên bản 1.0 và chứng minh ứng dụng có thị trường khả thi ngay từ đầu. Nhưng nếu bạn biết bạn sẽ có nhiều hơn một ngôn ngữ hoặc văn hóa, hãy hỗ trợ bản địa hóa ngay từ đầu.

4. Đối với phiên bản 1.0, đừng lo lắng quá nhiều về các mô-đun thả xuống hoặc API dịch vụ ưa thích. Nếu bạn đã có rất nhiều kinh nghiệm trong các framework có thể tái sử dụng, bạn sẽ có thể có công cụ này trong phiên bản 1.0, nhưng nếu bạn thiếu kinh nghiệm về kiểu kiến ​​trúc này, bạn sẽ lãng phí quá nhiều thời gian vào các tính năng này trong phiên bản 1.x và có thể sẽ vẫn nhận được nó sai và phải tái kiến ​​trúc trong phiên bản 2.x anyway.

5. Đảm bảo ứng dụng có báo cáo thực sự tốt. Đối với các loại ứng dụng bạn đang nói về, đây sẽ là những gì quyết định nếu ứng dụng thậm chí có một thị trường ở tất cả. Bạn cần báo cáo đẹp không chỉ có thể lọc/lọc được trên màn hình mà còn có thể in được. Đặt tiền và thời gian của bạn vào này ra khỏi cổng.

Answer 2

Điều quan trọng nhất là thiết kế nó theo cách hoàn toàn giống như vậy, tức là không có thông tin cụ thể nào được mã hóa hoặc nhúng cứng.

Mọi thứ cụ thể của khách hàng phải được định cấu hình thông qua siêu dữ liệu. Cách bạn làm điều này hoàn toàn tùy thuộc vào bạn, nhưng các cách chính là thông qua các tệp XML, Cơ sở dữ liệu hoặc các tệp thuộc tính.

Nếu bạn thiết kế theo cách này, nó có thể được bán cho bất kỳ số lượng khách hàng nào mà mỗi người sẽ có tệp hoặc dữ liệu cấu hình của riêng họ.

Answer 3

Abarax đã đưa ra một câu trả lời tuyệt vời, tôi muốn nhấn mạnh rằng bạn nên xem xét bản địa hóa - cho cả ngôn ngữ nói (tiếng Anh, tiếng Pháp, tiếng Đức, v.v.) và ngôn ngữ của tổ chức, ví dụ: một số nơi có thể gọi nó là một Timesheet, Docket hoặc Work Order, và mỗi người sẽ rên rỉ và rên rỉ và rên rỉ nếu mọi thứ không phù hợp với những gì họ đã luôn gọi là một cái gì đó.

Answer 4

Nếu bạn đang sử dụng công nghệ nguồn mở, hãy dành một chút thời gian lưu giữ tất cả thông tin giấy phép ở một nơi.