c# - sirve - ¿Qué son los servicios de WCF RIA?
wcf ria services que es (2)
Odio el sitio de MSDN para los servicios WCF RIA. No dice lo que es, solo dice lo que hace. Dice lo que puede lograr, pero no dice por qué lo necesito.
Por ejemplo:
"Un problema común al desarrollar una solución RIA de n niveles es coordinar la lógica de la aplicación entre el nivel medio y el nivel de presentación".
Bueno, no significa mucho para mí.
"RIA Services soluciona este problema proporcionando componentes de framework, herramientas y servicios que hacen que la lógica de la aplicación en el servidor esté disponible para el cliente RIA sin que sea necesario que duplique esa lógica de programación manualmente. Puede crear un cliente RIA que conozca las reglas comerciales y saber que el cliente se actualiza automáticamente con la última lógica de nivel medio cada vez que se vuelve a compilar la solución ".
Entonces, ¿descarga archivos DLL del servidor? ¿Es un metadato que describe las reglas para los datos?
¿Así que qué es lo? ¿Es solo un complemento de VS 2010 para RAD? ¿O es una tecnología encima de WCF o debajo de ella o qué? ¿Dónde vive? Con datos, con servidor, ¿qué?
Le agradezco si puede resumir esto por favor, por favor.
Las últimas noticias: WCF RIA Services está muerto:
http://blogs.msmvps.com/deborahk/who-moved-my-cheese-ria-services/
Si desea utilizar los Servicios de RIA, han sido de origen abierto:
Los servicios de RIA son una tecnología del lado del servidor que genera automáticamente objetos del lado del cliente (Silverlight) que se encargan de la comunicación con el servidor y proporcionan validación del lado del cliente.
El objeto principal dentro de un servicio RIA es un DomainService , generalmente un LinqToEntitiesDomainService que está conectado a un modelo LinqToEntities.
La clave para recordar en los servicios de RIA es que es principalmente un truco de construcción sofisticado. Cuando crea un servicio de dominio y compila su solución, se genera una representación de su servicio de dominio del lado del cliente. Esta representación del lado del cliente tiene la misma interfaz. Supongamos que crea un servicio de CustomerService con un método IQueryable<Customer> GetCustomersByCountry . Cuando crea su solución, se genera una clase dentro de su proyecto de Silverlight llamada CustomerContext que tiene un método GetCustomersByCountryQuery . Ahora puede usar este método en el cliente como si lo estuviese llamando en el servidor.
Las actualizaciones, inserciones y eliminaciones siguen un patrón diferente. Cuando crea un servicio de dominio, puede indicar si desea habilitar la edición. Los métodos correspondientes para actualizar / insertar / eliminar se generan luego en el servicio de dominio del lado del servidor. Sin embargo, la parte del lado del cliente no tiene estos métodos. Lo que tienes en tu CustomerContext es un método llamado SubmitChanges . Entonces, cómo funciona esto:
- Para las actualizaciones, simplemente actualice las propiedades de los clientes existentes (que recuperó a través de
GetCustomersByCountryQuery). - Para inserciones, usa
CustomerContext.Customers.Add(new Customer(...) {...}). - Para las eliminaciones, usa
CustomerContext.Customers.Remove(someCustomer).
Cuando termine de editar, llame a CustomerContext.SubmitChanges() .
En cuanto a la validación, puede decorar los objetos del lado del servidor con los atributos de validación del espacio de nombres System.ComponentModel.DataAnnotations . De nuevo, cuando construyes tu proyecto, el código de validación ahora se genera automáticamente para los objetos correspondientes del lado del cliente.
Espero que esta explicación te ayude un poco más.