asp.net - mvc - radio button asp net core

Entidades de seguimiento personal frente a entidades de POCO

Question

Estamos comenzando un nuevo producto basado en web en el que estamos planeando exponer nuestra lógica comercial a través de los servicios de WCF. Usaremos ASP.NET 4.0, C #, EF 4.0. En el futuro, queremos crear aplicaciones para iphone y aplicaciones WPF basadas en los servicios. He estado leyendo mucho sobre el uso de POCO vs Entidades de seguimiento automático (STE) y, según entiendo, las ECE no funcionan bien con el escenario web. ¿Alguien puede arrojar más luz sobre este tema?

Answer 1

Consulte http://msdn.microsoft.com/en-us/data/jj613924.aspx , ya que las ECE ya no se recomiendan. Microsoft recomienda utilizar cualquiera de ASP.NET Web API, WCF Data Services o Entity Framework API (operaciones complejas)

Answer 2

Las Entidades de seguimiento automático funcionan perfectamente en un entorno web MVC con WCF. He estado involucrado en 2 proyectos usándolos (uno en producción, uno casi).

Con las POCO perdería cualquier cambio en el seguimiento que crea mucho dolor adicional porque EF ahora tiene que volver a consultar para obtener información del estado. Si utilizas EF y WCF STE resuelves muchos problemas y haces que todo tu pipeline de persistencia sea realmente fluido.

¿Puede proporcionar una citación para este reclamo? "Las ECE no funcionan bien con el escenario web"

Answer 3

Para mí, STE es un concepto absolutamente erróneo. Es solo otra implementación de DataSet.

• En la aplicación ASP.NET, tendrá que almacenar STE en algún lugar entre las solicitudes. En la primera solicitud consultará su origen de datos para obtener STE y proporcionar datos en la página. En la próxima solicitud (postback), querrá modificar STE con datos devueltos del navegador. Para admitir el seguimiento, deberá usar el mismo STE que en la primera solicitud => tendrá que almacenar STE en viewstate (si desea usar ASP.NET WebForms) o sesión.
• STE es inútil para SOA o interoperabilidad. La lógica de seguimiento es parte de STE = se está ejecutando en el cliente. Si expone STE en el servicio, espera de inmediato que ese lado del cliente use las mismas características de rastreo incluidas en la lógica STE. Pero estas características no se proporcionan al otro lado automáticamente. En .NET los tiene porque comparte ensamblado con STE. Pero en otra plataforma tienes que explicarles a los desarrolladores cómo implementar la lógica STE para que funcione de tu lado. Este será probablemente el caso más limitante para usted debido a la aplicación de iPhone.

Answer 4

Si este servicio va a ser consumido por cualquier aplicación sobre la que no tenga control directo, probablemente debería considerar divorciarse de todo lo que tenga que ver con EF (o nHibernate o Linq2Sql o cualquier otra solución de administración de persistencia de datos) de sus servicios y sus datos transferir objetos Esto aislará los cambios internos de clientes rotos. Romper clientes es típicamente algo malo.