Có ai có lời khuyên hoặc mẹo sử dụng dịch vụ web làm mô hình trong ứng dụng ASP.Net MVC không? Tôi chưa từng thấy ai viết về việc này. Tôi muốn xây dựng một ứng dụng MVC, nhưng không buộc nó vào sử dụng một cơ sở dữ liệu cụ thể, cũng không giới hạn cơ sở dữ liệu cho ứng dụng MVC đơn lẻ. Tôi cảm thấy một dịch vụ web (RESTful, rất có thể là dịch vụ dữ liệu ADO.Net) là con đường để đi.ASP.Net MVC với dịch vụ web làm mô hình?
Chỉnh sửa 2010-11-27; làm rõ suy nghĩ của tôi, điều đó thực sự cần thiết.
Dịch vụ web cho thấy chức năng trên nhiều loại ứng dụng khác nhau, không phải cho trừu tượng trong một ứng dụng duy nhất, thường xuyên nhất. Có thể bạn đang suy nghĩ nhiều hơn về cách đóng gói các lệnh và đọc theo cách không can thiệp vào chương trình điều khiển/xem của bạn.
Sử dụng dịch vụ từ xe buýt dịch vụ nếu bạn sau khi tách và thực hiện mẫu không đồng bộ trong các trang không đồng bộ của mình. Bạn có thể thấy Rhino.ServiceBus, nServiceBus và MassTransit để triển khai bản địa .Net và RabbitMQ cho một số khác nhau http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/.
Chỉnh sửa: Tôi đã có thời gian để thử thỏ theo cách đẩy thông điệp vào dịch vụ của tôi, từ đó đẩy cập nhật lên ứng dụng lưu giữ sách. RabbitMQ là một nhà môi giới tin nhắn, hay còn gọi là MOM (thông điệp theo định hướng phần giữa) và bạn có thể sử dụng nó để gửi tin nhắn đến máy chủ ứng dụng của bạn.
Bạn cũng có thể chỉ cung cấp giao diện dịch vụ. Đọc Thiết kế điều khiển miền của Eric Evan để biết mô tả chi tiết hơn.
Giao diện dịch vụ REST-ful xử lý rất nhiều dữ liệu và cụ thể hơn với các tài nguyên có thể định địa chỉ. Nó có thể đơn giản hóa rất nhiều mô hình lập trình của bạn và cho phép kiểm soát tuyệt vời đầu ra thông qua giao thức HTTP. Mô hình lập trình sắp tới của WCF sử dụng phần còn lại thực như được định nghĩa trong luận án ban đầu, trong đó mỗi tài liệu nên ở một mức độ nào đó cung cấp URI để tiếp tục điều hướng. Có look at this. (Trong phiên bản đầu tiên của bài đăng này, tôi than thở REST vì bị 'chậm', bất kể điều đó có nghĩa là gì) API dựa trên REST cũng khá nhiều những gì sử dụng CouchDB và Riak.
ADO.Net là khá crap (!) [N + 1 vấn đề với bộ sưu tập lười vì mã để thực hiện, rò rỉ truy cập dữ liệu - bạn luôn cần bối cảnh db nơi mã truy vấn của bạn là vv] so với ví dụ LightSpeed (thương mại) hoặc NHibernate. Spring.Net cũng cho phép bạn bao bọc các giao diện dịch vụ trong giao diện của chúng với một mặt tiền dịch vụ web, nhưng (không cần duyệt trong một thời gian) Tôi nghĩ nó hơi quá xmly trong cấu hình của nó.
Chỉnh sửa 1: Với ADO.Net ở đây, ý tôi là "thực hành tốt nhất" mặc định với DataSets, DataAdapter và lặp lại nhiều hàng từ một DataReader; nó giống mã xấu và khó gỡ lỗi. Công cụ N + 1, vâng, đó là về khung thực thể.
(Edit 2: EntityFramework không gây ấn tượng với tôi trong hai!)
Sửa 1: Tạo lớp miền của bạn trong một hội đồng riêng biệt [aka. Core] và cung cấp tất cả các dịch vụ miền và ứng dụng tại đó, sau đó nhập cụm từ này từ ứng dụng MVC cụ thể của bạn. Quấn dữ liệu truy cập vào một số DAO/Repository, thông qua một giao diện trong hội đồng cốt lõi của bạn, mà lắp ráp dữ liệu của bạn sau đó tham khảo và thực hiện. Kết nối giao diện và triển khai với IoC. Bạn thậm chí có thể lập trình một cái gì đó để khám phá dịch vụ năng động với các xe buýt dịch vụ đã đề cập ở trên, để giải quyết các giao diện. WCF sử dụng các giao diện như thế này và do đó thực hiện hầu hết các dịch vụ trên; bạn có thể cung cấp một subcomponentresolver trong thùng chứa IoC của bạn để làm điều này tự động.
Chỉnh sửa 2: Một kết hợp tuyệt vời cho những điều trên sẽ là CQRS + EventSourcing + ReactiveExtensions. Mô hình viết của bạn sẽ có các lệnh, mô hình miền của bạn sẽ quyết định có chấp nhận chúng hay không, nó sẽ đẩy các sự kiện vào đường dẫn mở rộng phản ứng, có lẽ cũng trên RabbitMQ, mà mô hình đọc của bạn sẽ tiêu thụ.
Cập nhật 2010/01/02 (chỉnh sửa 1)
Các jest của ý tưởng của tôi đã được hệ thống hóa bởi một cái gì đó gọi là MindTouch Dream. Họ đã thực hiện một screencast, nơi họ đối xử gần như tất cả các phần của một ứng dụng web như là một (web) -service, mà cũng được tiếp xúc với REST.
Họ đã tạo ra một khung công tác song song cao bằng cách sử dụng các đồng điều phối để xử lý việc này, bao gồm cả nhóm chủ đề đàn hồi của riêng họ.
Đối với tất cả những người nói này trong câu hỏi này, trong khuôn mặt của bạn: p! Listen to this screen-cast, đặc biệt là ở 12 phút.
Nếu bạn là thành loại này của chương trình, có một cái nhìn tại how monads work và their implementations in C#. Bạn cũng có thể đọc lên trên CoRoutines.
Chúc mừng năm mới!
Cập nhật 2010-11-27 (chỉnh sửa 2)
Hóa ra coroutines đã productized với nhiệm vụ thư viện song song từ Microsoft. Nhiệm vụ của bạn bây giờ thực hiện các tính năng tương tự, khi nó triển khai IAsyncResult. Caliburn là một khuôn khổ tuyệt vời sử dụng chúng.
Tiện ích mở rộng phản ứng đã thực hiện việc hiểu đơn lẻ ở cấp độ không đồng bộ tiếp theo.
Thế giới ALT.Net dường như đang chuyển động theo hướng tôi đã nói khi tôi viết câu trả lời này lần đầu tiên, mặc dù với các kiểu kiến trúc mới mà tôi biết rất ít.
Bạn nên xác định mô hình của mình theo cách không phụ thuộc vào truy cập dữ liệu, ví dụ: sử dụng mẫu Repository. Sau đó, bạn có thể tạo các triển khai cụ thể được hỗ trợ bởi các công nghệ truy cập dữ liệu cụ thể (Dịch vụ Web, SQL, v.v.).
Khả năng hoặc hữu ích của ứng dụng MVC sẽ được tách riêng khỏi cơ sở dữ liệu của bạn? Bạn đã thấy bao lâu một lần, trong cuộc đời ứng dụng của bạn, một sự thay đổi từ SQL Server sang Oracle? Từ 10 năm qua của dự án tôi đã giao, nó không bao giờ xảy ra.
Kiến trúc giống như hành tây, chúng có các lớp trừu tượng bên trên những thứ mà chúng phụ thuộc. Và nếu bạn định sử dụng RDBMS để lưu trữ, đó là cốt lõi của kiến trúc của bạn. Tóm tắt bản thân bạn từ DB để bạn có thể trao đổi nó xung quanh là rất nhiều sai lầm.
Bây giờ bạn có thể tách quyền truy cập cơ sở dữ liệu của mình khỏi miền của mình và mẫu lưu trữ là một trong các cách để thực hiện điều đó. Hầu hết các giải pháp trưởng thành sử dụng ORM những ngày này, vì vậy bạn có thể muốn có một cái nhìn NHibernate nếu bạn muốn có một công nghệ trưởng thành, hoặc ActiveRecord/linq2sql cho một mẫu hồ sơ hoạt động đơn giản trên đầu trang của dữ liệu của bạn.
Bây giờ bạn đã có chiến lược dữ liệu tại chỗ, bạn có một miền thuộc loại nào đó.Khi bạn hiển thị dữ liệu cho khách hàng của mình, bạn có thể chọn làm như vậy thông qua mẫu MVC, nơi bạn thường gửi DTO được tạo từ miền của mình để hiển thị hoặc bạn có thể quyết định tận dụng kiểu kiến trúc như REST để cung cấp nhiều hệ thống được ghép lỏng hơn bằng cách cung cấp liên kết và đại diện tùy chỉnh.
Bạn đi từ khớp nối chặt chẽ với khớp nối lỏng hơn khi bạn đi tới các lớp bên ngoài của giải pháp.
Nếu câu hỏi của bạn là xây dựng một ứng dụng MVC trên nền kiến trúc REST hoặc dịch vụ web và sử dụng nó làm mô hình ... Tại sao phải bận tâm? Nếu bạn sắp có một mô hình miền, tại sao không sử dụng lại mô hình đó trong hệ thống của bạn và các dịch vụ của bạn ở nơi nào có ý nghĩa?
Tạo giao diện người dùng từ ứng dụng MVC và tạo tài liệu cần thiết cho kiến trúc RESTful là hai ngữ cảnh hoàn toàn khác nhau, dựa trên một bối cảnh sẽ gây đau nhiều hơn mức cần thiết. Và bạn đang hy sinh hiệu suất.
Phụ thuộc vào kịch bản chính xác của bạn, nhưng dịch vụ dựa trên XML từ xa làm mô hình trong MVC, từ kinh nghiệm, không phải là ý tưởng hay, có thể là quá kỹ thuật và bỏ qua nhu cầu tên miền bắt đầu.
Ngày càng có nhiều ứng dụng doanh nghiệp được yêu cầu để có thể sử dụng cơ sở dữ liệu từ bất kỳ nhà cung cấp nào và phần mềm của bạn sẽ có thể thực hiện điều đó. Rất nhiều công ty có giấy phép cho Oracle ví dụ, nhưng bây giờ đang nghiêng về phía MySql. – Liao
Yêu cầu chuyển đổi cơ sở dữ liệu là một sự trừu tượng đắt tiền để áp đặt, và một công tắc đắt tiền để thực hiện. Đó là một trong những yêu cầu về kiến trúc phi hành gia mà khi chuyển đổi xảy ra, chi phí vẫn còn nhiều. Đối với hầu hết các trường hợp, một kịch bản tốt hơn rất nhiều so với kiến trúc sư cho một cơ sở dữ liệu. Nên yêu cầu cho một chuyển đổi xảy ra, nó sẽ chi phí anyway, và tôi sẽ tranh luận nó có thể chi phí ít hơn nhiều so với thiết kế cho các tình huống bất khả tri cơ sở dữ liệu. Ngay cả khi sử dụng ORM a la nhibernate, một vẫn sẽ có mâu thuẫn, không tương thích, phân loại biến, v.v. – SerialSeb
"Khả năng hoặc hữu ích của ứng dụng MVC sẽ được tách riêng khỏi cơ sở dữ liệu của bạn?" - Tôi không thấy lý do tại sao mọi poster khác cần phải nói với người hỏi câu hỏi rằng họ sai, trừ khi nó phù hợp với mô hình tự điều chỉnh của bạn từ chối các điều kiện tiên quyết của câu hỏi (rằng anh ta đặt lên) thay vì hỏi cốt lõi của câu hỏi chính nó! – Henrik
Nó thực sự phụ thuộc vào kích thước của dự án mvc này. Tôi sẽ nói giữ UI và Domain trong cùng một môi trường đang chạy nếu trang web sẽ được sử dụng bởi một số ít người dùng (< 5000). Ở phía bên kia, nếu bạn đang có kế hoạch trên một trang web mà có thể được truy cập bởi hàng triệu, bạn phải suy nghĩ phân phối và điều đó có nghĩa là bạn cần phải xây dựng trang web của bạn theo cách nó có thể mở rộng quy mô lên/ra. Điều đó có nghĩa là bạn có thể cần phải sử dụng các máy chủ phụ (Web, ứng dụng và cơ sở dữ liệu).
Để điều này hoạt động tốt, bạn cần tách riêng trang web giao diện người dùng mvc khỏi ứng dụng. Lớp ứng dụng thường chứa mô hình miền của bạn và có thể được tiếp xúc thông qua WCF hoặc một xe buýt dịch vụ. Tôi thích một Service Bus vì nó đáng tin cậy hơn và có thể sử dụng hàng đợi dai dẳng như msmq.
Tôi hy vọng điều này sẽ giúp
Bạn đang so sánh ADO.Net với ORM (đoạn # 4)? Ý của bạn là LINQ2SQL hoặc EF? – MotoWilliams
Vâng, ORM sử dụng ADO.Net; Tôi đã so sánh việc sử dụng chúng như là giao diện chính cho cơ sở dữ liệu, trong trường hợp đó nó có ý nghĩa. – Henrik
N + 1 trên ado.net? Ý tôi là nghiêm túc .... Bộ sưu tập được tải xuống lười biếng chỉ gây ra N + 1 trong một số trường hợp nhất định mà bạn sẽ tiếp cận với nhibernate. Đó là lý do tại sao bạn có mỗi truy vấn mong muốn tải thông qua các chiến lược tìm nạp trong bất kỳ ORM hợp lý nào, bao gồm linq2sql. Khi điều đó xảy ra, nhibernate thực sự đang chạy ado.net bên dưới cho kết nối db của bạn ... – SerialSeb