24 de diciembre de 2014

Separar entidades de negocio desde modelo de Entity framework

Al trabajar con Entity Framework se crean las clases poco en files con extensión .tt, para tener esas clases que representan las entidades de negocio del modelo, se puede...porque hay muchas formas...seguir estos simples pasos

Crear un nuevo proyecto, tipo Solución en blanco


Utilizando el lenguaje C#, agregar dos proyectos a la solución creada, de tipo Librería
de Clases: DAL y Entities y eliminar las clases Class1.cs que crean por defecto





Ahora, agregar un nuevo item al proyecto DAL, sera un 


en la siguiente pantalla escoger desde una base de datos y luego seleccionar la conexión y las tablas, dependerá de cada proyecto las tablas que se vayan a seleccionar para el modelo, así que sin mas suponemos que pueden crear un simple modelo de base de dtos utilizando Entity Framework así que después de todos los pasos que asumo a bien ustedes pueden realizar y la solución quedaría así


Ahora si, debemos dar click derecho en el proyecto DAL y seleccionar Open Folder in File Explorer...  luego buscar y cortar el file Modelo.tt, luego dar click derecho en el proyecto Entities, escoger de nuevo  Open Folder in File Explorer y pegarlo en la carpeta del proyecto Entities tal como muestra la secuencia








Ahora dar doble click en Modelo.tt dentro del proyecto Entitites y modificar el string InputFile de esto:


a esto y salvar cambios:


Ahora en el proyecto DAL, dar click derecho en Modelo.Context.tt y seleccionar Propiedades


Especificar el NameSpace donde se encuentra Modelo.tt


y por ultimo, hacer referencia desde el proyecto DAL al proyecto Entities


y eso es todo, ya tienes separadas alas entidades del negocio de la capa de datos que es donde se encuentra el modelo de Entity Framework para este ejemplo, tu puedes tener tu modelo donde mas te convenga, aqui lo importante es mostrar como hacer la separación de las clases desde el modelo.









23 de diciembre de 2014

CRUD consumiendo un servicio WCF

Toca realizar operaciones a la base de datos en SQL Server desde un servicio WCF, para esto hay dos maneras, ya sea a la antigua con ADO.NET utilizando procedimientos almacenados y los famosos SqlCommand o bien por el lado del ORM Entity Framework.

En esta entrada se utilizaran procedimientos almacenados sobre la siguiente tabla llamada Employee sobre una base de datos a la que llame ejemplo


el web.config del proyecto queda con el Integrated Security = SSPI asi:


Se trabajara sobre el servicio WCF que se creo en entradas anteriores, en este se agregara una carpeta con nombre Clases y dentro de esta agregaremos una clase con el nombre Employee, esta clase sera la entidad de negocio que representara a la tabla Employee, mira el desarrollo del WCF aquí


El código de la clase Employee.cs se muestra a continuación, tener en cuenta los espacios de nombre System.Runtime.Serialization y System.ComponentModel


El procedimiento almacenado que se utilizara se llama IngresarDatos y se agrega sobre la base de datos ejemplo sobre la que también se creo la tabla Employee, el código T-SQL se muestra


Sobre la interfaz o contrato IServicio_WCF del servicio WCF se debe agregar la operación IngresarDatosEmployee, la cual retornara un string y recibe una entidad Employee


El código de la clase Servicio_WCF que implementara la interfaz, desarrollara la operación que se acaba de agregar, el código se muestra


Ahora toca ejecutar el servicio WCF, ya esta debidamente hospedado en el servidor IIS es por eso que se obtiene la dirección web que se resalta en la imagen y la cual debemos copiar pues la necesitaremos a continuación para agregar la referencia de nuestro servicio WCF desde un cliente, para referencia sobre como hospedar un servicio WCF en IIS dejo este enlace


Creamos un nuevo cliente que sera una aplicacion de Windows Forms llamada WindowsFormsApplication1 y agregamos la referencia al servidor WCF, para esto se debe escoger Add Service Reference... desde la aplicación de escritorio


y en la parte de Address pegamos la dirección web que anteriormente habíamos copiado y que hace referencia al servicio WCF creado y presionamos el botón Go


de la imagen anterior, en el Namespace cambie el ServiceReference1 por Servicio, así la manera de invocar al servicio WCF sera Servicio.Servicio_WCFClient test = new Servicio.Servicio_WCFClient();

la pantalla que se mostrara al usuario tendrá el siguiente diseño, para esta entrada solo se codificara el evento del boton Ingresar

El código del evento click del botón Ingresar se muestra a continuación, se hace la referencia al servicio WCF y a la entidad de negocios Employee:


Al completar los datos como se muestra en pantalla y presionar el boton Ingresar aparecerá un MessageBox con un mensaje de confirmación, en caso se de algun error este igualmente se mostrara en el MessageBox, se han hecho las validaciones básicas, ustedes pueden agregar validaciones funcionales para su proyecto.


Para finalizar ejecuto una simple ejecución select sobre la tabla Employee para que muestre el registro que se acaba de ingresar...eso es todo, en la siguiente entrada se mostrara como trabajar WCF con Entity Framework.












17 de diciembre de 2014

Crear, hospedar(IIS) y consumir WCF Service App

WCF es la evolución de las tecnologías Web Service de Microsoft de años anteriores ya que provee un amplio rango de funcionalidad por encima de web services, con mejores características en aspectos de calidad como flexibilidad, portabilidad y mantenibilidad, también vale mencionar que hay clases que no se pueden serializar a través de un web service en .NET que si tienen soporte en WCF (HashTable por ejemplo).

Los servicios de WCF pueden funcionar bajo distintos protocolos, aunque el http es el mas común,ademas los servicios de WCF puede ser alojados en distintos host, no necesariamente tiene que ser el IIS, puede ser un Windows Service que desarrolles, o una aplicación de consola que este ejecutándose y exponga servicio, etc

WCF Service Application y WCF Service Library

Voy a poner explicita una imagen de una explicación que me pareció concisa para exponer cuales son las diferencias entre WCF Service App y WCF Service Library...


Par Interface-clase servicio WCF

Al momento de desarrollar un servicio WCF se debe tener en cuenta dos partes: una interface que representara el contrato de nuestra aplicación(me refiero a aquello que estas obligado a implementar)que se decora con [ServiceContract] y las operaciones a exponer que se decoran con el atributo [OperationContract], ademas se necesita una clase que debe implementar esa interfaz, aquí un ejemplo sencillo antes de continuar
[ServiceContract]
public interface ITest{  

[OperationContract]
string ShowMessage(string strMsg);
        }

public class Service : ITest{  
 public string ShowMessage(string strMsg)
  {
   return strMsg;
  }
    }

Para hacer el ejemplo interesante vamos a utilizar una base de datos con tres tablitas, recuerda que el ejemplo puede hacerse tan complejo o tan básico como tu lo necesites, valida la justificación anterior aquí esta mi humilde base de datos


Creando el servicio WCF

toca abrir el VS y crear un nuevo proyecto del tipo WCF: WCF Service Application, con nombre Host-Service, este agregara una interfaz y una clase que implementara la interfaz tal como muestro en la figura


lo que vamos a hacer ahora es eliminar los dos archivos que señalo en la figura y agregar un nuevo item al proyecto del tipo WCF Service


Agregando item con nombre Servicio-WCF, este archivo sera la clase que implementara nuestra interface y sera el archivo que se hospedara en nuestro servidor y que expondrá los servicios a las demás aplicaciones


Al agregar el item WCF Service con nombre Servicio-WCF se agregan dos archivos: una interface y con nombre IServicio-WCF y el archivo Servicio-WCF.svc, nuestro proyecto quedara de la siguiente manera visto desde Solution Explorer


Al crear un servicio de WCF, la primera tarea es definir un contrato de servicio, esto no es mas que una interface que especifica los métodos que brindara el WCF Service y que luego tendrán que ser implementados por una clase especifica La interfaz queda de la siguiente manera, se creara un método para mostrar la típica cadena de texto para mostrar un saludo, pero con eso no llegaremos lejos así que también vamos a crear un método para mostrar el estado de una conexión a SQL Server y un método para mostrar datos de una tabla utilizando Dataset(No es la mejor manera pero como primera aproximación ayudara bastante)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
using System.Data;

namespace App_WCF{
  
[ServiceContract]
 public interface IServicio_WCF{

[OperationContract]
string PruebaTexto(string valor);

[OperationContract]
string PruebaConexion();

[OperationContract]
DataSet PoblarDGV();
 
  }}
Ya tenemos la interface ahora toca codificar la clase que implementa esta interface, esta clase es Servicio-WCF.svc...antes de continuar quiero dejar claro que esta es una primera aproximación, puedes encontrar ejemplos en los que se cree un proyecto tipo WCF Service Library en los cuales la clase o bien clases(puedes utilizar las que quieras aquí el que manda eres tu) que implementa la o las interfaces(de nuevo, el que manda eres tu) son archivos con extensión cs, es decir, simples clases, por lo que no estas atado a utilizar el archivo con extensión svc como la clase que implementa la interfaz...mas adelante haré un ejemplo con WCF Service Library y veras las mínimas pero considerables diferencias, de momento sigamos, aquí esta el código que implementa la interface

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;
using System.Data;
using System.Data.SqlClient;
using System.Configuration;

namespace App_WCF{

public class Servicio_WCF : IServicio_WCF{
    
 public string PruebaTexto(string valor){
   string mensaje = string.Empty;
    try
       {
        mensaje = "Saludos " +valor+  " "+ "Mensaje de prueba desde el Servicio-WCF";
       }
    catch (Exception ex)
       {
        throw new ArgumentException(ex.Message);
       }
  return mensaje;
 }

public DataSet PoblarDGV(){
 string conexion = ConfigurationManager.ConnectionStrings["conexion"].ConnectionString.ToString();
 SqlConnection sql = new SqlConnection();
 sql.ConnectionString = conexion;
 DataTable dt = new DataTable();
 DataSet ds = new DataSet();
  try{
   using (sql){
    sql.Open();
    SqlDataAdapter da = new SqlDataAdapter("select * from empleado", sql);
    da.Fill(ds);
    return ds;                        
     }
    }
  catch (Exception ex){             
   throw new ArgumentException(ex.Message);
 }}          
        
public string PruebaConexion(){
 string mensaje = string.Empty;
 string conexion= ConfigurationManager.ConnectionStrings["conexion"].ConnectionString.ToString();
 SqlConnection sql= new SqlConnection();
 sql.ConnectionString= conexion;
            
 try{
  sql.Open();
  if (sql == null)
  {
  mensaje = "la conexion no tiene ningun valor";
  }
  else if (sql.State == ConnectionState.Closed)
  {
  mensaje = "la conexion no esta Open";
  }
  else
  {
  mensaje = sql.State.ToString(); ;
  }
  sql.Close();
  return mensaje;
  }
               
  catch (Exception ex) { return ex.Message; }
}}}

muestro ademas como queda mi web.Config, que pasa con los endpoint? que pasa con los serviceBehavior? es acaso que no voy a configurar nada? sigan leyendo...
<configuration>
  <connectionStrings>
      <add name="conexion"
        connectionString="Data Source=LINGONET\SQLEXPRESS;Initial Catalog=ejemplo;Integrated Security=SSPI"
        providerName="System.Data.SqlClient" />
  </connectionStrings>
    <system.web>
    <customErrors mode="Off"/>
    <authentication mode="Windows"/>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
 <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
    <directoryBrowse enabled="true"/>
  </system.webServer>
</configuration>

Al utilizar WCF en nuestro web.Config deberemos especificar los endpoints pero en este ejemplo solo especificamos la cadena de conexión, no agregamos ningún endpoint, entonces como se espera que funcione el servicio WCF? facil, aprovechamos los Default Endpoints de WCF4, estos se agregaron porque la mayor queja de los programadores al utilizar WCF era la confusión que creaban los endpoints, era mas fácil codificar los métodos que exponía el servicio que crear un endpoint en el web.Config asi que se crearon los Default Endpoints.

estos son endpoints “preconfigurados” que se cargan automáticamente para cada dirección base creada. Al llamarse al método Open del ServiceHost, ya sea automáticamente por parte de IIS o manualmente cuando se hostea el servicio en una aplicación de consola, se crean estos bindings predeterminados haciendo uso del método AddDefaultEndpoints.

Un par de cuestiones a tener en cuenta:
1. Si se configura un endpoint en el fichero de configuración, ya no se hace efectiva la llamada a AddDefaultEndpoints.
2. Si aún así quisiéramos tener esos endpoints por defecto, siempre es posible llamar explícitamente al método AddDefaultEndpoints y añadir, a los endpoints definidos en el fichero de configuración, los que crea él por defecto.

Que nos ofrecen los default endpoints? una configuración basica por defecto que se considera como la más habitual con una dirección base con protocolo http, el binding por defecto es basicHttpBinding. Esta nueva técnica ha sido bautizada como Default Protocol Mapping. En cualquier caso, este mapeo también es configurable; si quisiéramos que por defecto la direcciones con protocolo se resolvieran con un binding de tipo wsHttpBinding, sería necesario agregar lo siguiente en el app.config/web.config:

  <system.serviceModel>
    <protocolMapping>
      <add scheme="http" binding="wsHttpBinding"/>
    </protocolMapping>
  </system.serviceModel>

OJO: en otra entrada de este blog mostrare como crear los endpoint ya que si eres un programador de respeto no te vas a quedar con los default endpoint, porque los utilizo aquí? porque es una introducción...recuerdas? ademas imagino no te hara daño el saber que existen y que si eres un principiante no tendrás que preocuparte(de momento) de los endpoints al crear tu primer servicio WCF.

Nos quedaría activar los metadatos del servicio para generar el fichero WSDL y enviar información detallada en caso de error. Ambas no son configuraciones por defecto del servicio, por lo que tendríamos que editar el fichero app.config/web.config e introducir lo siguiente:

<system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Si nos fijamos, veremos que no ha sido necesario ni darle un nombre al nuevo behavior del servicio, ni tampoco definir el servicio y asociarle el behavior, como hacíamos en el framework3.5. Esto se conoce como Default Behavior Configurations, configuraciones sin nombre que se van a aplicar a cualquier servicio que definamos. Tienen su contrapartida en los Default Binding Configurations, que realizan la misma función pero asociados a un tipo de binding. y listo, damos F5 y probamos los métodos, como ejemplo pruebo el método PruebaConexion()


Hospedar el servicio WCF

Ahora viene la parte de hospedar el servicio WCF, una de las ventajas es que no es obligaion que los hospedes en IIS, pero como nos quedamos con los default endpoints que utilizan una direccion base http, entonces hospedemolo en IIS, recuerda verificar los siguiente para el transporte de datos

<system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

ahora debemos verificar que el IIS esta debidamente instalado, para probarlo escriban localhost en la barra de direcciones de su browser y deberían tener esta pantalla...la imagen que les aparecerá dependerá de la versión de IIS que tengan instalado


ahora si damos click derecho sobre el servicio que creamos anteriormente y escogemos la opción View in Browser tal como muestro en la figura


Se abrirá el explorador determinado mostrando el servicio


Notar la dirección web que muestra, esta utilizando el IIS Express es por eso que muestra el Localhost:1997, el numero 1997 representa el puerto que asigna el IIS Express, lo que buscamos es hospedar el servicio en IIS y que simplemente la dirección web sea Localhost...manos a la obra, lo que viene es abrir el administrador de IIS, aquí lo que vamos a verificar sera el Application Pool, abrimos el IIS Manager y seleccionamos Application Pool, debemos tener instalado el framework 4.0


y damos click en Advanced Settings al lado derecho del panel, en esta ventana de configuraciones  deben cambiar el Identity por LocalSystem y verificar que la version del framework sea 4.0 tal como muestro en la figura (en caso no ser así recuerden que deben tener instalado el Framework 4.0)


Terminamos de configurar el IIS para hospedar nuestro servicio WCF, nada dificil verdad?...ahora regresemos a nuestro proyecto y sobre Servicio-WCF.svc damos click derecho y seleccionamos propiedades

y en este panel nos vamos a la opción web y cambiamos el IIS Express por Local IIS y seguidamente damos click en el botón Create Virtual Directory


ahora solo debemos regresar a nuestra aplicación, dar click derecho en el servicio y escoger View in Browser y...lo logramos, vean la direccion web y notaran la diferencia, ahora es solamente http://localhost/App-WCF/Servicio-WCF.svc lo que significa que esta instalado en nuestro servidor local y no utiliza un puerto temporal



Por ultimo vamos al IIS manager y podemos ver que en nuestra carpeta Sites se ha agregado el servicio App-WCF


Consumiendo el servicio WCF

Procedemos a crear un nuevo proyecto(muy aparte y nada que ver con el proyecto en que creamos el servicio WCF), crearemos una aplicación de Windows Forms aunque bien hubieramos tenido la opcion de utilizar WPF, WebForms o MVC.

como complemento, para comunicacion entre aplicaciones .NET se deberia utilizar un endpoint utilizando el binding="netTcpBinding" ademas muestro econnectionString del web.config del servicio WCF, es importante que Integrated Security = SSPI


Ahora en nuestro proyecto tendremos un WinForm con este diseño, lo hice así para que se adapte a la información que entregara el servicio WCF asi que ustedes disculparan la simplicidad


ahora viene lo importante, se va agregar una referencia del servicio WCF que acabamos de crear al proyecto de Windows Forms, como lo hacemos? debemos copiar la dirección web que se obtiene al dar click derecho sobre el servicio y escoger la opción View in browser para luego agregar la referencia de servicio tal como se muestra en la secuencia



en el Namespace cambie el ServiceReference1 por Servicio, asi la manera de invocar al servicio WCF sera 
Servicio.Servicio_WCFClient test = new Servicio.Servicio_WCFClient();


a continuación muestro el código del formulario para el evento button1_click, en este se invocara a los métodos públicos del servicio y se mostraran los resultados en los dos label y en el DataGridView1 tal como se muestra:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Data;
using System.Data.SqlClient;

namespace WindowsFormsApplication1{
    public partial class Form1 : Form{
        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e){
            Servicio.Servicio_WCFClient test = new Servicio.Servicio_WCFClient();
            string valor = textBox1.Text;
            label1.Text = test.PruebaTexto(valor);
            label2.Text = test.PruebaConexion();
            DataSet ds = new DataSet();
            ds = test.PoblarDGV();
            dataGridView1.DataSource=ds.Tables[0];
        }
    }
}
si, si...todo lo anterior esta bien para una primera aproximación, me atrevo a decir que tesaldra a la primera, pero hagamos algo mas interesante, algo como realizar operaciones sobre una base de datos, utilizar procedimientos almacenados y de paso serializar una clase, lo expongo en la entrada CRUD consumiendo un servicio WCF

12 de diciembre de 2014

Configuración de un servicio WCF

xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="serviceBehavior">
                    <serviceMetadata httpGetEnabled="true" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <services>
            <service behaviorConfiguration="serviceBehavior" name="WcfServiceLibrary.Service1">
                <endpoint binding="ws2007HttpBinding" contract="WcfServiceLibrary.IService1" />
                <host>
                    <baseAddresses>
                        <add baseAddress="http://localhost/WcfServiceApplication/Service1.svc" />
                    </baseAddresses>
                </host>
            </service>
        </services>
    </system.serviceModel>
</configuration>

¿No hay configuración? ¿Cómo es posible? Pues gracias a los Default Endpoints. Son endpoints “preconfigurados” que se cargan automáticamente para cada dirección base creada. Al llamarse al método Open del ServiceHost, ya sea automáticamente por parte de IIS o manualmente cuando se hostea el servicio en una aplicación de consola, se crean estos bindings predeterminados haciendo uso del método AddDefaultEndpoints. Un par de cuestiones a tener en cuenta:
  • Si se configura un endpoint en el fichero de configuración, ya no se hace efectiva la llamada a AddDefaultEndpoints.
  • Si aún así quisiéramos tener esos endpoints por defecto, siempre es posible llamar explícitamente al método AddDefaultEndpoints y añadir, a los endpoints definidos en el fichero de configuración, los que crea él por defecto.
Los bindings traen una configuración por defecto que se considera como más habitual. Por ejemplo, con una dirección base con protocolo http, el binding por defecto es basicHttpBinding. Esta nueva técnica ha sido bautizada como Default Protocol Mapping. En cualquier caso, este mapeo también es configurable; si quisiéramos que, por defecto, la direcciones con protocolo se resolvieran con un binding de tipo wsHttpBinding, sería necesario configurar lo siguiente en el app.config/web.config:
  <system.serviceModel>
    <protocolMapping>
      <add scheme="http" binding="wsHttpBinding"/>
    </protocolMapping>
  </system.serviceModel>
En este punto, tendríamos nuestro servicio hosteado en IIS. Nos quedaría activar los metadatos del servicio para generar el fichero WSDL y enviar información detallada en caso de error. Ambas no son configuraciones por defecto del servicio, por lo que tendríamos que editar el fichero app.config/web.config e introducir lo siguiente:
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
Si nos fijamos, veremos que no ha sido necesario ni darle un nombre al nuevo behavior del servicio, ni tampoco definir el servicio y asociarle el behavior, como hacíamos en 3.5. Esto se conoce como Default Behavior Configurations, configuraciones sin nombre que se van a aplicar a cualquier servicio que definamos. Tienen su contrapartida en los Default Binding Configurations, que realizan la misma función pero asociados a un tipo de binding.
Como se ha podido ver a lo largo del post, la configuración en WCF4, al menos la más habitual, se ha simplificado enormemente. Los nostálgicos de la sencillez de los servicios ASMX han perdido la principal razón para no dar el paso a WCF.
Now a question comes to mind, How is this done in WCF 4?
The answer to that is: When the host application calls the Open method on the ServiceHost instance, it builds an internal service description from the application configuration file. Then it checks the count of configured endpoints. If it is still zero then it will call the AddDefaultEndpoints public method and the method will add a default endpoint per base address for each service contract implemented by the service.
With WCF 4, it is possible to define the default behavior configurations for services and endpoints.
<behaviors>
  <serviceBehaviors>
    <behavior>
      <serviceMetadata httpGetEnabled="true"/>
    </behavior>
  </serviceBehaviors>
</behaviors>

Endpoints will be mentioned in the web.config file on the created service.
<system.serviceModel>
<services>
      <service name="MathService"
        behaviorConfiguration="MathServiceBehavior">
       <endpoint
         address="http://localhost:8090/MyService/MathService.svc" contract="IMathService"
          binding="wsHttpBinding"/> 
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MathServiceBehavior">
          <serviceMetadata httpGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Binding and Behavior

Binding

Simple definition for Binding describes how the client will communicate with service. We can understand with an example.
Consider a scenario say, I am creating a service that has to be used by two type of client. One of the client will access SOAP using http and other client will access Binary using TCP. How it can be done? With Web service it is very difficult to achieve, but in WCF its just we need to add extra endpoint in the configuration file.
<system.serviceModel>
    <services>
      <service name="MathService"
        behaviorConfiguration="MathServiceBehavior">
      <endpoint address="http://localhost:8090/MyService/MathService.svc" 
        contract="IMathService"
          binding="wsHttpBinding"/>
<endpoint address="net.tcp://localhost:8080/MyService/MathService.svc" 
contract="IMathService"
          binding="netTcpBinding"/> 
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MathServiceBehavior">
          <serviceMetadata httpGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

  
See how simple it is in WCF. Microsoft is making everything simple.cording to its scope: common behaviors affect all endpoints globally, service behaviors affect only service-related aspects, endpoint behaviors affect only endpoint-related properties, and operation-level behaviors affect particular operations.

Example:

In the below configuration information, I have mentioned the Behavior at Service level. In the service behavior I have mention the servieMetadata node with attribute httGetEnabled='true'. This attribute will specifies the publication of the service metadata. Similarly we can add more behavior to the service.
<system.serviceModel>
    <services>
      <service name="MathService"
        behaviorConfiguration="MathServiceBehavior">
        <endpoint address="" contract="IMathService"
          binding="wsHttpBinding"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MathServiceBehavior">
          <serviceMetadata httpGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>