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

Anti Patrones Parte I

¿Por dónde empezar?, un anti patrón, por así decirlo, es un patrón mal aplicado que nos lleva a una mala solución. Veamos algunos.

Anti-patrones de Gestión de Proyectos

1- Productividad a toda costa: La empresa busca la productividad a costa de la calidad del software y de la calidad de vida de sus empleados, intenta normalizar los puestos de trabajo quitando en la medida de lo posible, los permisos a los programadores para que no dañen los sistemas operativos, monitoriza a los equipos de trabajo y actúa cortando la visibilidad de ciertas páginas o reuniones de programadores, al final la gente abandona la empresa cuando la situación ya es insostenible, esto suele ocurrir en ciclos de uno o dos años.

2- Mas programadores, para reducir el tiempo de entrega. Muchas veces para arreglar el retraso en la entrega de un proyecto se suman mas programadores a un equipo, lo cual suele juegar en contra llevando a un mayor retraso.

3- Jefes/as que no saben coordinar un equipo, el proyecto no se monitoree de manera correcta. Esto suele llevar a retrasos en los tiempos de entrega o entregas incompletas.

Anti-Patrones en el código

1- Vulcan Code: se caracteriza por tener clases con grandes cantidades de código, poco documentadas variables declaradas que no se usan o que no son necesarias.

Se utiliza un estilo poco claro en evolución la arquitectura.

Es un proyecto que tiene mucho código por reemplazar o mejorar por ejemplo: métodos que no se invocan, objetos o componentes que no se utilizan, interfaces abandonadas, etc.

2- Spaghetti Code: si bien tiene mucha similitud con “Vulcan Code”, este anti-patrón se caracteriza además por utilizar mas de un lenguaje en el desarrollo y por tener una arquitectura frágil con lo cual el menor cambio afecta de manera drástica toda la estructura del sistema.

3- Ghosts (Fantasmas): se caracteriza por tener varias clases en el sistema o tablas en la base de datos con pocas responsabilidades. Este anti-patrón suele darse cuando un modelo de análisis y/o diseño es inestable: el diseño no suele coincidir con la implementación y ampliar el sistema es poco probable, dado que habiendo tanto “fantasma”, encontrar los elementos relevantes es imposible.

Anti-Patrones en la Arquitectura

1- Reinventar la rueda, es uno de los anti-patrones más típicos, se caracteriza por la poca reutilización de código y el reescribir código en lugar de implementar componentes ya existentes.

2- Stovepipe (cañerías de calefacción): Se refiere a construir un sistema que difícilmente se puede mantener ya que está ensamblando por componentes poco relacionados. Un ejemplo de esto sería la creación de islas dentro de la misma empresa (cada departamento crea su propio subdepartamento de sistemas). “Islas” independientes, y en conflicto unas con otras. Cada isla desarrolla la parte del sistema que necesita para satisfacer sus requerimientos, sin preocuparse por el resto (no existe un plan o eje guía), los resultados son una pobre o nula interoperabilidad y un incremento en los costos. Este anti-patrón es mas habitual de lo que se cree.

Espero les guste este articulo. Pronto escribiré la segunda parte.

Gracias por visitar mi blog.

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

Error al crear o mostrar diagramas en SQL Server 2008

Hola mis lectores amigos, hoy les traigo una solución sencilla para el problema de generar o visualizar un diagrama de una base de datos que no ha sido creada por nosotros.

A mas de uno seguramente le ha pasado que luego de anexar o restaurar una base de datos y luego disponerse a crear a visualizar un diagrama sale el siguiente error

TITLE: Microsoft SQL Server Management Studio
——————————
Database diagram support objects cannot be installed because this database does not have a valid owner. To continue, first use the Files page of the Database Properties dialog box or the ALTER AUTHORIZATION statement to set the database owner to a valid login, then add the database diagram support objects.
——————————
BUTTONS:
OK

No vamos a preguntarnos el porque (bueno si alguien lo quiere hago unn post explicando el porque), sino que vamos a ir directamente a la solución creamos una nueva query y pegamos esto

EXEC sp_dbcmptlevel ‘AdventureWorks2008R2′, ’90’;
go
ALTER AUTHORIZATION ON DATABASE::AdventureWorks2008R2 TO “LapTop\Admin”
go
use AdventureWorks2008R2
go
EXECUTE AS USER = N’dbo’ REVERT
go

NOTA: deben reemplazar el AdventureWorks2008R2 por el nombre de su base de datos y el LapTop\Admin por el usuario que utilizan para loguearse en su SQL Server.

Espero les sirva, hasta el próximo post. Gracias por visitar mi blog