Generar una Clase Proxy de un Servicio Web

Hola gente, hoy les voy  contar algo que me pasó hace unos días, realizando mantenimiento de una aplicación, mas precisamente de un paquete SQL Server Integration Services (SiSS), en cual debía consumir un web services, me topé con la necesidad de crear una clase proxi para poder consumir dicho web services. Así que investigando un poco encontré un comando el cual se debe ejecutar en la consola de comandos de Visual Studio (para los que tienen Windows XP o 7, menú inicio – programas – Microsoft Visual Studio – Herramientas – Símbolo de Sistema de Herramientas de Visual Studio para los que tiene Windows 8 o Superior buscan Símbolo de Sistema de Herramientas de Visual Studio)  y pegar este comando

wsdl /l:vb /o:c:\ProxyClass “url WebServices.asmx”

Como se darán cuenta, he resaltado algunas cosas la primera es el leguaje en el que se va generar la clase (vb o cs), la segunda es la ruta de donde se va guardar el archivo y la tercera es la dirección url del servicio web (entre comillas).

Una vez generada la clase, la agregamos al proyecto y ya podemos crear una instancia de la misma. Algo  tener en cuenta es que dentro de la clase esta la url del servicio web en duro (harcodeada) para tener mayor flexibilidad, lo bueno sería almacenarla en un archivo de configuración.

Espero les sirva de ayuda y como siempre muchas gracias por visitar mi blog. Saludos

Examen 70-483 Programando en C#

Hola, si te interesa rendir la certificación 70-483. aquí te dejo el link de descarga del material de estudio http://1drv.ms/1fOZlvg

Descripción:

Editor: Microsoft Press
Por: Wouter de Kort
Año: 2013
Páginas: 384
Idioma: Inglés
Tamaño de archivo: 39.5 MB
Formato de archivo: PDF

Espero te sirva el aporte, ya sabes si deseas que trate algún tema en especial, sugiérelo en los comentarios.

Como siempre muchas gracias por visitar mi blog y por favor click en “Me gusta”

https://www.facebook.com/codigopuntonet

Hasta la próxima.

 

Buenas Practicas de Programción en c# Segunda Parte

Como lo prometido es deuda, aqui estoy con la segunda parte del post de Buenas Practicas de Programacion en c#.

Comencemos con SQL

En base de datos, es recomendable:

1. Stored Procedures deben nombrarse con prefijo “spr_”. NO usar nunca “sp_”, La razón es que: SQL Server reconoce el prefijo “sp_” como “System Stored Procedure”, es decir, un procedimiento almacenado de Sistema y lo buscaría en la Base de Datos “Master”.

2. Tablas “tbl_” ….

3. Vistas “vw_” …

Volviendo al código c#

1. Usa #region para agrupar código. En mi caso suelo usar de la siguiente manera

#región –[Variables Privadas]– #End Region

#región –[Propiedades Privadas]– #End Region

#región –[Metodos Privados]– #End Region

#región –[Eventos]– #End Region

#región –[Propiedades Publicas]– #End Region

#región –[Metodos Publicos]– #End Region

la idea es mantener las variables globales, las propiedades y los métodos, todos ellos privados en la parte superior del archivo y los elementos públicos en la parte inferior.

Metodos

1.  Un método debe tener entre 1 a 25 líneas de código. Si un método tiene más de 25 líneas de código, debes considerar refactorizarlo en métodos separados.

2. El nombre de los métodos debe decir lo que hace. Si el nombre del método es obvio, no hay necesidad de summary.

3. Un método debe tener solo “una tarea”. No combines más de una tarea en un solo método, aún si esas tareas son pequeñas.

4. Evita métodos y propiedades públicas, a menos que ellas realmente necesiten ser accedidas desde afuera de la clase. Usa “internal” si ellas solo son accedidas dentro del mismo ensamblado. Normalmente pocos usan esta buena práctica, es muy recomendable.

5. Evita pasar muchos parámetros a un método. Si tienes más de 5 parámetros, define una clase o una estructura. Esto reduce el consumo en memoria, evita la corrupción de datos, y disminuye la exigencia a los ciclos del procesador.

6. Si tienes un método que retorna una colección, devuelve una colección vacía en vez de null, si no existen datos que retornar. Esto permite hacer una verificación por un count en vez de por null y luego por count.

Constantes, strings y de mas

1. Usar constantes en el código, no es recomendado.  Se debe usar las constantes en el archivo de configuración o en la base de datos, de tal forma que si a futuro deben cambiarse, sea menor el impacto.

2. Si debes comprar cadenas de texto recuerda convertirlas a mayúsculas o minúsculas según corresponda, estoy permitirá una mejor comparación.

3. Usa string.Empty en vez de “”.

4. Usa enum en donde sea requerido. No uses números o cadenas para indicar valores fijos

enum TipoCorreo
{
Html,
TextoPlano
}

switch ( tipoCorreo )
{
case TipoCorreo.Html:
//hacer algo
break;
case TipoCorreo.TextoPlano:
// hacer algo

}

5. Los eventos no deben contener el código que ejecute la acción requerida. En vez de ello, se debe llamar a otro método desde dicho evento, ejemplo:

protected void btnObtenerDatos_Click(object sender, EventArgs e)
{
ObtenerDatos();
}

6. De la mano del punto anterior, no invoques desde código el evento Click, en vez de ello llama al método que es invocado desde el evento click.

7. No utilices código duro en rutas o letras de dispositivos. Obtén la ruta desde código.

8. Cuando inicia la aplicación, ejecuta una clase de “auto verificación” para asegurarte que todos los archivos requeridos y las dependencias están disponibles en las ubicaciones esperadas. Verifica las conexiones a la base de datos. En caso de algún problema, muestra un mensaje amigable al usuario.

9. Si el archivo de configuración requerido no se encuentra, la aplicación debe ser capaz de crear uno con valores predeterminados.

10. Cuando despliegues mensajes de error,  el mensaje también debe decirle lo que el usuario que debe hacer para resolver el problema. En vez de un mensaje como “Error al actualizar tus datos.”, sugiere lo que el usuario debe hacer: “Error al actualizar los datos, comprueba que tienes acceso a internet e inténtalo de nuevo.”.

11. Evita tener clases muy grandes. Si una sola clase tiene más de 1000 líneas de código, es un buen candidato para refactorizar. Divídelos lógicamente en dos o más clases.

Bueno esto es todo por hoy, muchas gracias por leer mi blog y espero te sirva de ayuda. En estos días prepararé la ultima entrega de buenas practicas, si deseas de que trate algún tema en especial por favor comunícamelo. Hasta la próxima.

Buenas Practicas de Programción en c# Primera Parte

Hola, hoy voy a empezar con la primera parte de las buenas Prácticas de Programación en .NET, esto no es algo que se me ocurrió a mí, sino que son estándares usados para programar y así generar un código mas entendible por si a futuro debe ser analizado y/o modificado por algún colega no sufra dolores de cabeza intentando entender lo que hicimos, bueno sin mas vueltas vamos al grano.

Comencemos con un poco de teoría de notaciones:

Los términos “notación Pascal” y “notación de Camell”

Notación Pascal: El primer carácter de todas las palabras se escribe en Mayúsculas y los otros caracteres en minúsculas. Ejemplo: EstadoDeEnvio

Notación de Camell: El primer carácter de todas las palabras, excepto de la primera palabra se escribe en Mayúsculas y los otros caracteres en minúsculas. Ejemplo: estadoDeEnvio

Buenas Practicas I

No se deben usar  guiones bajos (_) para nombres de variables locales generalmente el guión bajo (_) está reservado para variables globales, de tal forma que puedan ser identificadas de las variables locales.

Variables booleanas: es conveniente usar el prefijo “Es” ó “Is” para variables de tipo boolean o prefijos similares. Ejemplo: private bool EsValido private bool IsActivo La propuesta de “Is” es la más aceptada, ya que es coherente con las propiedades de uso global de .NET, por ejemplo: objeto.IsEmpty(); de esta manera el IntelliSense agrupa de una forma más coherente.

Los nombres de los espacios de nombres deben seguir el siguiente estándar: <NombreDeCompañía>.<NombreDeProducto>.<MóduloSuperior>.<MóduloInferior>

namespace northwind.GestionDeFacturacion.Facturas.Proveedores

Los nombres de Clases o Métodos y funciones deben seguir el estándar:

<Accion/Verbo en Inglés><descripción> GetProveedores(); AddProveedores();

Lo cual permite al IntelliSense agrupe de manera más optima con el resto de métodos generales de los objetos.

Usar prefijos apropiado para cada elemento de la interfaz gráfica. Dado que .NET tiene una gran cantidad de controles, se tiende a utilizar los siguientes prefijos

Label: lbl

TextBox: txt

DataGrid: dtg

Button: btn

ImageButton: Imb

Hyperlink hlk

DropDownList: ddl

ListBox: lst

DataList: dtl

Repeater: rep

Checkbox: chk

CheckboxList: cbl

RadioButton: rbt

RadioButtonlist: rbl

Image: img

Panel: pan

PlaceHolder: phd

Table: tbl

Validators: val

Gracias por tu visita, espero te haya servido de ayuda, pronto estaré escribiendo la segunda parte de buenas prácticas, si deseas de que escriba sobre algún tema en especial por favor comunícamelo.

Saludos

NullReferenceException ArgumentNullException

¿Porque pasarle null a los métodos?,  en determinados casos hay métodos que reciben un objeto con valor null, pero la realidad es que no es una buena práctica aunque si muy usada en el mundillo de la programación, cuántos de nosotros hemos visto algo así:

public void GuardarDatosCompra(Datos datosCompra)
{
if datosCompra == null)
throw new ArgumentNullException("datosCompra");
}

Entonces si pasamos un nulo como argumento, lo que logramos es recibir un ArgumentNullException en vez de un NullReferenceException.

Lo cierto es que ambas excepciones, para este caso, nos dicen lo mismo: le enviamos un objeto con valor null a un método y no deberíamos. ¿Cuál es la solución? para este caso en el que no se aceptan valores nulos, se deberían validar que estén cargados todos los valores correspondientes al objeto y así evitar agregar líneas de código sin sentido.

Gracias por tu visita, espero te haya servido de ayuda, pronto estaré escribiendo más sobre buenas prácticas, si deseas de que escriba de algún tema en especial por favor comunícamelo.

Saludos