El proyecto actual en el que estoy trabajando utiliza extensamente servicios web y está hecho en .net 3.5. Ahora, a medida que avanzamos en la implementación de la segunda fase, estamos confundidos si deberíamos usar WCF o el servicio web como se hizo anteriormente. Además, hay algo nuevo que puede ser útil y está creando .net 4.0 con respecto a los servicios web o WCF.¿Qué elegir? Servicio web ASMX o WCF en .net 3.5?
Acabamos de terminar un nuevo proyecto utilizando WCF en lugar de ASMX Web Services por primera vez. Estamos MUY felices con los resultados, pero sabemos que hubo una curva de aprendizaje abrupta. Aun así, estamos extremadamente satisfechos con los resultados generales y sabemos que esta es la base de todo lo que Microsoft está haciendo en el futuro y ha valido la pena por completo, con verrugas y todo eso.
Rápida beneficios WE adquirida a lo largo de ASMX:
1) (detrás del firewall) llamadas internas-servicio-servicio que utilizamos la red: la unión TCP, que es mucho más rápido que el jabón
2) Hemos habilitado un punto final net: tcp y un punto final "web" en el mismo servicio con solo una actualización de archivo de configuración (no hay cambios de código)
3) Pudimos crear servicios web RESTful compatibles con AJAX con solo configuración cambia y usa el DataContractJsonSerializer que ya está integrado. T De lo contrario, tendríamos que escribir un controlador HTTP (ashx) y manejar la mayor parte de la serialización Json y el análisis de url a mano.
4) Como nuestro sitio necesita escalar para optimizar el rendimiento y la estabilidad, estamos considerando la conversión a utilizar una estructura de mensajería basada en MSMQ que sea asíncrona Y garantizada y participe en las transacciones; WCF proporciona una vinculación de MSMQ que requiere un cambio de código de poco a nada en nuestros servicios, solo las actualizaciones de referencia y la configuración de MSMQ correctamente con los servicios existentes (y la adición de atributos para los límites de transacción).
PERO SEA ADVERTIDO: Invertir realmente en el aprendizaje de este (compre el libro azul de O-Reily y repárelo). Hay cosas como cambios de nombre de argumento durante el desarrollo que realmente no rompen las referencias de servicio sino que dan como resultado que se pasen argumentos nulos (manejo de sesgo de versión incorporada), modelos de alojamiento a considerar (Servicio de Windows vs. IIS) e instanciación Modelos y FaultExceptions a todos REALMENTE entienden. No entramos y tuvimos algunos dolores. ¡Pero seguimos adelante y estamos muy contentos con nuestros aprendizajes y las oportunidades de flexibilidad y crecimiento que ya no estamos vinculados a ASMX!
Hay diferentes puntos a considerar antes de saltar a WCF:
- WCF es arquitectónicamente más robusto y promueve las mejores prácticas.
- Si sabe lo que está haciendo es "suave como la seda", si no lo hace, se encontrará con un paseo .
- ¿Tiene tiempo suficiente para completar la conversión de sus servicios?
Por último, me gustaría decir que, si usted tiene el tiempo, la ostentación y el músculo para hacer la actualización. Vale la pena. Si asmx satisface todas las necesidades, puede continuar con los servicios web.
otros dos aspectos:
No importa lo que decida esto por el lado del servidor, que puede consumir fácilmente servicios web WCF y servicios que utilizan solamente WCF en el lado del cliente. Esto es valioso si consume múltiples servicios con un solo cliente.
Ha solicitado los próximos temas. Si tiene en cuenta la computación en la nube: es posible alojar Servicios WCF en Windows Azure.
ASMX es grande y simple - pero está muy limitado en muchos aspectos:
WCF soluciona esto y ofrece mucho más que eso. Puede alojar sus servicios WCF en IIS, o auto-host en una aplicación de consola o Servicio Win NT, según sea necesario. Puede conectar sus servicios WCF utilizando HTTP, TCP/IP, MSMQ, protocolos punto a punto, conductos con nombre para comunicaciones en la máquina y mucho más.
I would definitivamente recomiendo usted va con WCF. Es un poco más complejo que ASMX, ¡pero también ofrece muchas más capacidades y opciones!
En cuanto a resoures: está el MSDN WCF Developer Center que tiene de todo, desde los tutoriales para principiantes hasta los artículos y el código de muestra.
Además, le recomiendo que echar un vistazo a la Pluralsight screen casts on WCF - es una excelente serie que va desde "Creating your first WCF service" y "Creating your first WCF client" todo el camino a los temas más avanzados. Aaron Skonnard explica muy bien todo en 10 a 15 minutos de screencasts, ¡muy recomendado!
Con WCF o ASMX, asegúrese de agregar sus servicios a sus páginas utilizando la etiqueta asp: ScriptManager. Creará proxys JavaScript para usted, y la ventaja es que no tiene que construir ningún análisis, independientemente del protocolo subyacente. Es muy, muy agradable. Este ejemplo es ASMX, pero es tan limpio como usar WCF.
<asp:ScriptManager ID="ScriptManager1" runat="server">
<Services>
<asp:ServiceReference Path="~/WebServices/Admin/HospitalLocationService.asmx" InlineScript="true" />
</Services>
</asp:ScriptManager>
Además, se puede hacer ASMX enviar JSON mediante la adición de la ScriptService y ScriptMethod atributos:
<System.Web.Services.WebService(Namespace:="http://www.fujimed.com/")> _
<System.Web.Services.WebServiceBinding(ConformsTo:=WsiProfiles.BasicProfile1_1)> _
<ToolboxItem(False)> _
<ScriptService()> _
Public Class HospitalLocationService
Inherits System.Web.Services.WebService
<WebMethod()> _
<ScriptMethod()> _
Public Function GetAll() As List(Of HospitalLocationEntity)
Return (New HospitalLocation()).GetAll().Data
End Function
<WebMethod()> _
<ScriptMethod()> _
Public Function GetByID(ByVal ID As Integer) As HospitalLocationEntity
Return (New HospitalLocation()).GetHospitalLocation(ID).Data
End Function
End Class
consumo del servicio, sin necesidad de analizar (esto es lo que hace el ScriptManager para usted):
function editLocation(id) {
vRIS.HospitalLocationService.GetByID(id, getComplete, getError);
}
function getComplete(results, context, methodName) {
document.all['txtLocation'].value = results.Location;
document.all['txtInterfaceID'].value = results.InterfaceID;
document.all['selActive'].value = results.Active ? "true" : "false";
document.all['hdnLocationID'].value = results.ID.toString();
}
function getError(errorInfo, context, methodName) {
Alert(methodName + " : " + errorInfo);
document.all['txtLocation'].value = "";
document.all['txtInterfaceID'].value = "";
document.all['selActive'].value = "false";
document.all['hdnLocationID'].value = "";
}
Editado para agregar: Con todo lo anterior basado en ASMX, aún así utilizaría WCF, por versatilidad y por la capacidad de definir contratos de datos. Además, investigue WCF RIA Services; apuntan a la compatibilidad con AJAX y Silverlight, y automatiza gran parte de la configuración de WCF.
El modelo WCF es mucho más flexible, esencialmente - si solo lo usa para presentar un modelo básico de http utilizando basic-profile y xml, con objetos proxy - se verá muy similar.
Una breve lista de diferencias sin embargo:
Tony es la actualización que vale la pena los esfuerzos ... quiero decir, ¿observa un rendimiento considerable, funcionalidad y mejora de flexibilidad al cambiar de asmx a WCF? – HotTester
+1 puntos positivos Tony – Perpetualcoder
Más información sobre el rendimiento aquí: http://msdn.microsoft.com/en-us/library/bb310550.aspx – magnus