Đánh giá Sharepoint vs ASP.NET là nền tảng phát triển

Question

Tôi đang đánh giá Sharepoint (không phải MOSS) so với ASP.NET làm nền tảng phát triển cho giải pháp sắp tới cho nhóm của chúng tôi. Chúng tôi sẽ phát triển một giải pháp cho việc triển khai rộng (chúng tôi hy vọng) trên nhiều môi trường khác nhau. Tôi đang xác định các danh mục để đánh giá ưu/nhược điểm cho từng lựa chọn nền tảng. Tôi đã chọn các danh mục có thể áp dụng cho các yêu cầu giải pháp của chúng tôi và điều đó sẽ ảnh hưởng đến năng suất của nhà phát triển/người kiểm tra. Bất cứ ai có thể nghĩ về bất kỳ loại khác mà có thể thích hợp cho một sự so sánh? Bất cứ ai có thể cung cấp bất kỳ chi tiết về kinh nghiệm của bạn với hai nền tảng liên quan đến bất kỳ loại nào?

Một số thông tin khác, chúng tôi có khung thời gian hai tháng ngắn để phát hành nội dung nào đó, vì vậy chúng tôi đang ưu tiên các tính năng như chúng tôi nói. Chúng ta thấy Sharepoint như là một cách để có được một cái gì đó ra khỏi cửa một cách nhanh chóng trong khi tận dụng khung UI cho một UI cơ bản, bảo mật và danh sách và thư viện tài liệu để lưu trữ.

Development Environment

suất Developer

Testability chức năng

Developer Testability (đơn vị thử nghiệm)

Vai trò Bảo mật dựa trên

xem dựa an

Trải nghiệm người dùng

Cơ sở dữ liệu - Dễ dàng phát triển với Sharepoint dựa trên việc sử dụng danh sách. Tuy nhiên, việc thêm báo cáo làm yêu cầu sẽ làm cho việc sử dụng danh sách trở nên gây trở ngại.

Reporting - Sharepoint làm cho điều này khó

Document Repository - giải pháp của chúng tôi sẽ đòi hỏi nhiều thư viện tài liệu đính kèm hiện vật đến các yếu tố giải pháp

Bao bì

Lắp đặt - Sharepoint cho chúng ta cài đặt famr dễ dàng qua WSP .

Khả năng mở rộng

Khả năng mở rộng

phức tạp

Conceptual Liêm (ranh giới miền)

Redundancy/Replication/Sao lưu/Phục hồi Hỗ trợ

Answer 1

chính thức, để phát triển các giải pháp WSS, tất cả các nhà phát triển của bạn sẽ cần phải có môi trường phát triển của họ chạy trên một máy chủ WSS. Tôi cho rằng đó là một tiêu cực.

Xem nhiều nhận xét dưới Sharepoint tools support in Visual Studio bởi Somasegar.

Tôi muốn nói rằng vì bạn có thời hạn ngắn, bạn cũng nên xem xét thực tế là có cộng đồng nhà phát triển SharePoint nhỏ hơn nhiều so với cộng đồng ASP.NET. So sánh số lượng bài viết trên SO được gắn thẻ "ASP.NET" thay vì các bài viết được gắn thẻ "SharePoint".

Tôi muốn sử dụng ASP.NET trong thời gian ngắn, hiểu rằng bạn có thể cấu trúc lại ứng dụng của mình để sử dụng SharePoint trong thời gian dài hơn. Sử dụng cấu trúc cơ sở dữ liệu tương tự như danh sách hoặc các loại nội dung khác mà bạn đã tạo trong SharePoint. Giữ một mô hình triển khai tương tự. Vui lòng sử dụng quy trình làm việc, nhưng có lẽ nên song song với các tính năng của quy trình làm việc của SharePoint. Bạn thậm chí có thể đặt ra các trang của bạn theo cách tương tự. Điều này sẽ giúp bạn chuyển sang SharePoint dễ dàng hơn khi bạn có nhiều thời gian hơn.

Answer 2

Tôi không thấy chi phí.

Answer 3

Giải pháp của bạn có liên quan đến việc cộng tác hay quản lý nội dung web không? Nếu không, việc thêm SharePoint vào danh sách kết hợp sẽ không phải là một ý tưởng tuyệt vời.

Sử dụng WSS 3.0 làm nền tảng phát triển thay vì ASP.NET sẽ yêu cầu một số biện minh nghiêm trọng và không thể nói từ mô tả giới hạn giải pháp của bạn tại sao bạn thậm chí còn suy ngẫm về điều đó.

Trên tất cả các khía cạnh đo lường của bạn, việc tạo phát triển trên nền tảng SharePoint sẽ thêm tính đồng nhất và do đó chi phí cho bất kỳ nỗ lực phát triển nào.

Cập nhật

tôi thấy an ninh Sharepoint, thư viện tài liệu, khung giao diện người dùng, và thiếu cần phải xây dựng và thử nghiệm một DB như productivty lớn chất hỗ trợ. Đó là những Sharepoint tính năng mà chúng ta rất có thể hưởng lợi từ

Những lợi ích của SharePoint cho những mặt hàng đang xa nặng hơn bởi những khía cạnh chi phí học tập, mã hóa và hỗ trợ SharePoint. ASP.NET có các giải pháp dễ dàng cho các mục này và theo cách dễ quản lý hơn. Sau khi sử dụng cả hai sản phẩm mà bạn sẽ muốn ở lại với ASP.Net

Hãy nhớ rằng danh sách SharePoint không có bất kỳ loại vẹn quan hệ như vậy tạo ra bất cứ điều gì nhiều hơn một mối quan hệ không đáng kể giữa danh sách trong SharePoint sẽ kết thúc ồ ạt đắt hơn tạo một câu lệnh nối và một số procs được lưu trữ.

Nếu không biết thêm chi tiết về dự án, tôi hoàn toàn không thể loại trừ SharePoint làm giải pháp.

Mặc dù có thể sử dụng SharePoint làm nền tảng phát triển, nếu bạn không có chuyên gia SharePoint làm việc với bạn có thể trả lời câu hỏi của bạn, bạn sẽ không có đủ kỹ năng SharePoint trong dự án của bạn để thành công.

Answer 4

Khả năng mở rộng
Hạn chế cấp phép
Khả năng mở rộng
phức tạp
Conceptual Liêm (ranh giới miền)
Vendor Lockin/Hệ thống mở Hỗ trợ
Redundancy/Replication/Sao lưu/Phục hồi Hỗ trợ

Answer 5

Chúng tôi sử dụng SharePoint làm thành phần cho hầu hết các ứng dụng mà chúng tôi xây dựng cho khả năng tạo và quản lý danh sách và loại nội dung (và tự động CRUD), phiên bản, mô hình quyền và công cụ quy trình làm việc.

Chúng tôi đã phát triển SLAM, Trình quản lý danh sách SharePoint, để khắc phục các hạn chế rõ ràng về dữ liệu SharePoint không quan hệ. Bởi vì nó đẩy dữ liệu SharePoint vào SQL Server, nó cho phép chúng tôi sử dụng SharePoint chỉ trên "phụ trợ" chỉ với ASP.NET trên giao diện người dùng, một cấu hình chúng tôi sử dụng thường xuyên.

Chúng tôi đã phát hành SLAM như một dự án mã nguồn mở để phần còn lại của cộng đồng phát triển có thể tận dụng cách tiếp cận này và giúp chúng tôi mở rộng nó.

http://slam.codeplex.com

Chúc mừng Slamming!

Allan