Silverlight puede usar WCF, servicios web, servicios basados en REST, servicios .NET RIA, pero parece que los servicios Silverlight y .NET RIA son los preferidos.¿Cuáles son los peligros de utilizar .NET RIA Services en Silverlight?
Quiero saber si hay problemas comunes [que pueden ser un impedimento si se avanza con este combo] que haya visto en la implementación práctica de SL con .NET RIA Services.
Gracias, Rahul
Trabajar con metadatos (y escribir por sí mismo) es realmente el dolor en el culo. Especialmente cuando necesitas actualizar tu modelo. Las aplicaciones de RIA se ven bastante bien en una base de datos pequeña, pero si trabajas con un modelo que consta de docenas de entidades, pasarás más tiempo actualizando metadatos que programando la aplicación. Esto también está relacionado con la definición de validación y todos los mensajes de validación y descripción sobre las propiedades de los recursos. Pero hemos creado algunas plantillas T4 para que todo se genere automáticamente.
Por otro lado, estamos utilizando RIA en dos proyectos y debo decir que es lo mejor que podemos obtener. Tuvimos algunos problemas con la validación, pero se puede resolver (validando antes de verificar si el valor de la propiedad ha cambiado). Y una vez que conoce la gestión de memoria con RIA (no desea cargar todo el databse en la memoria del cliente, etc.), se puede utilizar en la vida real.
Desafortunadamente, no hay nada malo, por lo que si, por ejemplo, planifica que otros clientes que su aplicación SL se conecten al servidor, probablemente debería mirar en otro lugar (¿WCP Data Services, quizás?). O si no desea actualizar los datos de su cliente, veo que RIA es excesivo.
servicios de Ria y descansar servicios ofrece un acceso bastante similares a las clases del lado del servidor, que a menudo son las clases Entity Framework (pero no necessarely ... ya que varios programadores que parece creer). La principal ventaja de Ria Services es que manejan la validación mediante el uso de anotaciones de datos en clases del lado del servidor y lo hacen de una manera inteligente: generan automáticamente clases secundarias del cliente con las mismas anotaciones de datos y las valida implementando automáticamente INotifyDataError en el clase del lado del cliente. Si uno usa atributos personalizados y pone la extensión .shared.cs (o .vb) esas definiciones de atributo se copian en el cliente silverlight y se usan en la validación del lado del cliente, de lo contrario se usan solo para realizar la validación del lado del servidor ... ... para más información pls ver mi blog
SIGUIENDO MI RESPUESTA ANTERIOR AQUÍ LAS DESVENTAJAS DE LOS SERVICIOS DE RIA: En el otro extremo, la desventaja de los servicios de ria es su falta de flexibilidad. Principalmente es como un tubo que conecta una clase en el lado del servidor con su representante del lado del cliente de tal forma que opera en la clase del lado del cliente como si estuviera operando directamente en la clase del lado del servidor. Si la forma en que este "tubo" manejado está bien para su aplicación, obtendrá muchos servicios gratis (sin escribir ningún código ...). Sin embargo, existen limitaciones que no se pueden eliminar específicamente:
1) No tiene la misma libertad para definir el comportamiento, el atributo, etc., para modificar la forma en que se comporta el servicio web. Por ejemplo, no puede definir una transacción distribuida que involucre más de un servicio web. Es difícil agregar nuevos puntos finales ... Tiene que escribir código ... no simplemente modificar un archivo de configuración.
2) Solo puede definir un método Insertar/una actualización/obtener uno para cada clase. Si aplica el filtrado a la consulta del lado del cliente a través de LINQ, se aplica solo en el cliente, es decir, todos los datos se descargan del servidor y luego se filtran en el cliente.Por el contrario, si utiliza un servicio de datos WCF basado en OData y define una consulta en el lado del cliente. ESTA CONSULTA SE TRADUCE EN UNA CONSULTA DE DESCANSO (una consulta codificada en la URL de la solicitud) POR LO TANTO, SÓLO SE DESCARGAN LOS DATOS QUE USTED REQUIERE DE SU FILTRO DESDE EL SERVIDOR. Para obtener más información sobre el servicio de datos WCF, consulte here.
3) En contraste con los Servicios de datos de WCF, no se ofrece ningún servicio de Validación como con el servicio de Ria. Sin embargo, puede seguir utilizando annotatios de datos con la ayuda de mi kit de herramientas de validación para WPF & Silverlight, que está disponible de forma gratuita here
Se equivoca al filtrar con los servicios de RIA. Solo tiene que hacer el filtrado en la consulta que obtiene del contexto de RIA (por ejemplo, GetCustomersQuery()) y luego pasarlo a domainContext.Load(). Luego, todo el filtrado y la clasificación se realizan en el servidor (servidor de la base de datos, para ser precisos, ya que la consulta se transfiere al proveedor subyacente, generalmente EF/L2S, y se translata a SQL). – gius
¡Sí, ese es el punto! Todo el filtrado SOLO SE DECIDE EN EL SERVIDOR. ¡No puede DECIDIR en el CLIENTE un filtro que se aplicará en el servidor! Eso es lo que no puedes decirle al servidor ... por favor dame esto ... La única forma de hacerlo es redefiniendo el método en el servidor. A diferencia de los servicios de datos de WCF EN EL CLIENTE, puede definir un filtro que se ejecutará AL DÍA. Esto significa MÁS Y MÁS FLEXIBILIDAD –
Puede realizar una consulta definida en el servidor (incluye, filtrado y pedido puede estar allí), luego trabajar con ella más adelante en el cliente (agregar cláusulas Where, OrderBy), y finalmente devolverla al servidor para cargarlo. – gius
He estado usando RIA-Servicios por unos pocos meses y un par de aplicaciones y encontró que diferen Puedo hacer que haga prácticamente todo lo que necesito. Le ahorra MUCHA cantidad de tiempo mediante el uso inteligente de la generación de código para encargarse de la mayoría de las tuberías.
Se usa mejor si está creando una aplicación CRUD directa usando EF, si ese es el caso, entonces debería estar bien.
Si está haciendo algo un poco diferente, entonces tomará un poco más de trabajo, pero sigue siendo (en mi opinión) la mejor opción para obtener datos para su cliente Silverlight. Hay algunas pequeñas molestias, pero no topes de espectáculo que he encontrado.
Por ejemplo, lo he usado con Credenciales de SQL (registros de usuario en la aplicación Silverlight utilizando su inicio de sesión de SQL y creo dinámicamente una cadena de conexión usando el nombre de usuario + contraseña). Esto tomó un poco más de trabajo pero funciona bien.
También lo he usado para devolver datos al cliente de Procedimientos almacenados en lugar de Entidades, de nuevo, esto requiere un poco más de trabajo pero funciona bien.
He estado utilizando SL4 + EF para nuestro desarrollo empresarial y lo encontré, es difícil de desarrollar con EF si se usa el modelo predeterminado de desarrollo de caja. Lo que quiero decir es que, en cualquier pantalla que desarrolles, para los datos que usas EF con una tabla/vista, entonces rápidamente se borra tu modelo. Después de agregar 20 páginas nuevas con 6 a 10 tablas/vistas ahora es muy difícil agregar entidades en el edmx. Personalmente no me gusta el borrón. Si ve algunas de las preguntas que he hecho y basándose en las respuestas que parecen para el desarrollo a nivel empresarial, no use las características de EF integradas en la caja, cree un modelo de dominio usando POCO con PI y luego utilícelo para desarrollar su aplicación. Todavía no he completado uno con éxito, así que no tengo un resultado personal en esto. Otra cosa es que noté que EF no está relacionado en sí sino SL en sí mismo. Dedique un tiempo y comprenda PRISM/MEF/Caliburn y use eso para crear su aplicación. Uno de los problemas que no me gustan en SL es la capacidad de prueba, a pesar de que las pruebas de unidad SL están ahí, en sí mismo no es un buen marco de prueba de unidades. También probar EF no es muy fácil. Con PRISM/MEF/Caliburn no solo las pruebas son fáciles y también su desarrollo será verdaderamente modular. Así que antes de comenzar su desarrollo, mi recomendación es observar uno de los marcos y, en lugar de usar EF out of box, use POCO para crear su modelo de dominio y luego use POCO para usarlo en SL. Espero que esto ayude.
Hola, no estoy seguro de que entiendas bien RIA. EF está en el servidor pero RIA crea sus propias entidades en el cliente. ¿De qué sirve usar POCO en lugar de EF? Solo veo más trabajo con él: EF crea entidades e inserta/actualiza/elimina funciones para ti. – gius
Disculpa que no represento el RIA en eso. Mi pensamiento inicial es que EF se borró, no RIA. Perdón otra vez :) – Nair
RIA es una forma de cómo obtener datos del servidor de aplicaciones para el cliente. Por lo tanto, crea un servicio en el servidor y DomainContext y Entidades en el cliente. Trabajar con RIA desde el cliente es bastante cercano a EF/L2S debido al contexto (la diferencia es que todas las acciones de RIA son asincrónicas) .Desde RIA a la base de datos, depende de usted la tecnología que use; solo debe insertar su código personalizado en las funciones del servicio RIA como GetCustomers, InsertCustomer, UpdateCustomer , DeleteCustomer. También debe crear metadatos que le digan a RIA qué propiedades pasan de las entidades del servidor al cliente. – gius
Estoy realmente decepcionado con MS. Como es obvio a partir de la discusión sobre este tema, no soy el único que a veces se confunde con todas las "herramientas" que nos brinda la EM. El problema es que realmente extrañan algo de gestión y coordinación de MS.
El resultado es que hay productos muy similares con funcionalidades similares donde uno hace una cosa mejor y otro más. Y nadie puede decir cuál es mejor usar o incluso cuál será compatible en la próxima versión.
Tengo dos ejemplos.
Entity Framework vs LINQ to SQL en .NET 3.5 Estos fueron muy similares, ambos hicieron lo mismo. L2S estaba destinado a ser mejor para proyectos más pequeños, EF para empresas. L2S tenía un diseñador mucho mejor y una mejor implementación de LINQ. Se suponía que EF podía mapear más tablas de bases de datos a una entidad, pero esto nunca funcionó realmente bien. Y, por cierto, incluso EF4 no tiene una característica muy útil de L2S que es la función AssociateWith<>. Y de repente, L2S ya no es compatible y todos deberían usar EF. Debería haber alguien que al principio dijera "Detente, tenemos dos tecnologías similares. Dejemos que los dos equipos se junten y hagamos un producto con lo mejor de ambos".
RIA services vs. WCF Data services De nuevo, el mismo problema. Dos equipos distintos trabajando en dos productos similares. Ambos con algunas mejores características que el otro. Pero definitivamente, podría haber un producto con las características de ambos.
¿Cómo debemos decidir cuál usar (además de dedicar mucho tiempo a dominar ambos)? ¿Cuál será desaprobado?
... esto es probablemente para una publicación de blog, no para responder aquí. Lo siento, solo necesitaba escribirlo en algún lado y dado que se hablaba mucho sobre estos temas, parecía ser un lugar apropiado. Definitivamente intentaré escribir sobre eso más tarde.
Estoy de acuerdo Gius. Trabajo para Microsoft, y yo mismo estaba confundido. La razón por la que llegué a SO, es porque quería conocer una opinión clara del mundo exterior. También quería ver si hay muchos tipos que estarían dispuestos a explicar si RIA se ha convertido en un cuello de botella para su desarrollo. Aparentemente de esta discusión, parece que los servicios de RIA probablemente no serán un impedimento si uno decide ir con eso. –
En una nota personal, creo que el problema ahora es la elección. Hay demasiadas cosas para poner al día, y es aún más difícil decidir cuál es mejor. –
He escrito una publicación en mi blog sobre Ria WCF Data Services y WCF Rest Service usando también algunas de las conclusiones a las que llegamos aquí es here.
Los servicios de Ria se crean solo para ser utilizados con Silverlight. Son sustancialmente un "paquete" estándar listo para ser utilizado por Silverlight. La ventaja es que usted tiene una gran cantidad de servicios sin necesidad de escribir código es decir .:
Todo lo que hace Ria se puede hacer con WCF y con otro software disponible y, en particular, con los servicios de datos Wcf. Por ejemplo, para anotaciones de datos encontré this library que hacen un mejor trabajo que los servicios de Ria, el soporte para membresía solo requiere activar el extremo de membresía ya existente de un servicio WCF, y finalmente el problema de excepción se resuelve fácilmente escribiendo un comportamiento WCF. El código está disponible aquí: http: //www.silverlightshow.net/Storage/10Tips.zip El punto es que con Ria Service tienes todo esto con un clic del mouse. Por otro lado, los servicios de Ria son realmente difíciles de personalizar ... así que si no te gusta la solución estándar que ofrecen, simplemente no puedes usarlos
Gracias gius. Eso ayuda. Pero actualmente estoy tratando de encontrar una respuesta que me diga qué es lo que RIA no puede hacer en absoluto [o puede hacer frente a muchos dolores de cabeza y manipulaciones adicionales]. La forma en que lo veo, al actualizar los metadatos se encarga de un montón de validación para el cual tendría que escribir mucho código para empezar. ¿Pueden compartir un poco más detalles sobre las plantillas T4? –
Hemos creado plantillas T4 que generan metadatos (incluyendo validación y descripción), servicios (seleccionar, insertar, actualizar, eliminar funciones), recursos (cadenas de validación, cadenas de descripción) y procedimientos almacenados (insertar, actualizar, eliminar) basados en el modelo EF . Mi colega está limpiando las plantillas y preparando una publicación de blog donde se publicarán. Te lo haré saber tan pronto como se lance. – gius
Acerca de lo que RIA no puede: piense en ello como EF1 frente a EF4. Por lo tanto, es bastante difícil personalizar el comportamiento de las entidades, no puede usar POCO, todavía tiene que tratar con DomainContext. Pero como ya dije, probablemente sea la mejor forma de obtener datos del servidor en su aplicación de cliente SL. Hemos creado una aplicación bastante grande, tratada con datapaging, grids, master/details, DataForms, etc. y debo decir que RIA no fue el show stopper. No tome esto ya que estoy completamente satisfecho, esperamos con ansias RIA2. Simplemente no tendría miedo de usarlo. – gius