Componentes .Net 2/2

Esta es la segunda parte del articulo Componentes.Net 1/2, en el que indicaba posibles soluciones que pueden hacer que las aplicaciones o productos que desarrolles adquieran una dimensión diferente.

En esta segunda parte comentare mi experiencia vivida en este campo y la solución o soluciones que a mi juicio creo que ofrecen una mayor diversidad y funcionalidad.

Mi primera experiencia comenzó hace ya varios años cuando aún programaba (aún lo hago en casa para investigación y gestión), en esos años comprendí que muchas acciones eran muy repetitivas y que mediante la creación de objetos estos podían simplificar mi desarrollo.

Si estáis en esta aventura os deseo suerte y que disfrutéis, a mi me gusto y aprendí mucho sobre todo en cuanto a enfoque.

Creación de componentes propios

En esa aventura aprendes que debes realizar desarrollos genéricos que no debes encapsularte en resolver un único problema debido a que ese problema lo resolverás, sin embargo probablemente esa resolución a futuro te obligue a realizar otras acciones que no te gustan para añadir nuevas funcionalidades.

Para evitar esto solo recordar que todo objeto debe contener características concretas y claras no mezclando o intentando que un objeto o componente nuevo haga cosas que son de otro. Es decir un Texbox es lo que es y nunca será un combo ya que para eso existe el combo. Parece algo de cajón pero es así.

Lo siguiente es que no reutilices funcionalidades de objeto para darle una funcionalidad nueva, me explico, si haces una propiedad para que un Texbox se comporte como un autocompleted no intentes reutilizar esa misma propiedad de activación o las funciones que hayas realizado para ello para realizar otra funcionalidad. Un objeto no es una aplicación y algo pequeño se complicara demasiado y a futuro lo lamentaras.

Mi experiencia en PowerBuilder me ayudó mucho en mis inicios a adentrarme en el mundo de componentes gracias a su herencia y su tratamiento de objetos. No obstante a la hora de embarcarte en la aventura analiza bien que los componentes puedas mantenerlos. Visual Studio avanza muy rápido y es necesario estar al día, además las personas de la empresa cambian y ese técnico que los desarrollo ya puede que no este y que otros técnicos hagan el mismo trabajo, nuevos componentes.

Después de la diversión y cuando me toco gestionar proyectos y ver costes y recursos ahí se lio la gorda. Las cuentas no me salían y no veía rentable el tener un equipo manteniendo componentes y Objetos. Además de que toda persona nueva debía aprenderlos y no eran nada genéricos.

Con WPF además se abrió un mundo de posibilidades y que por el contrario se tendrían que realizar componentes nuevos.

Si realizáramos una evaluación mediante una herramienta de tomas de decisiones seguramente lleguéis al mismo punto que yo llegue.

En cuanto al tiempo que se invierte en la empresa es bastante más alto y necesitas recursos dedicado a la herramienta como un proyecto en el que suministren y atiendan las incidencias o solicitudes de otros equipos de desarrollo.

El coste es bastante más alto debido a ese equipo comparado con la compra de dicha licencia.

Formación: La información que se proporciona interna no es la misma que la que te puede entregar un producto para ello, además del posible soporte que contrates. Tampoco nos llevemos a engaño controlar y saber bien cómo funciona un componente de otro lleva tiempo.

Por otra parte los fuentes de esos componentes son dela empresa, de ahí que como comentare más adelante me decantase por la empresa que entrega los fuentes de dichos Componentes. Si, a sabiendas de que nunca los tocaría pero en caso de catástrofe mundial los tendría.

Mantenimiento, sería necesario ir adaptando los componentes a los framework y versiones de Visual Studio, mientras que la compra te aseguras la actualización.

Funcionalidades que pueden darte otras empresas con sus componentes que para ti sería inviable realizar por tiempos.

Cuanto tiempo podemos tardar en tener esos componentes nuevos en WPF para el proyecto, frente a unos que ya están hechos.

La que puede ser más importante y por eso la he dejado para la última, no somos una empresa que venda componentes o nos vayamos a dedicar a ello.

Decisión final: es mejor la compra. Como he dicho estoy a favor de crear los componentes si tienes los recursos, tiempo y coste, dan más seguridad y sabes bien como trabajarlos.

Componentes Externos

Una vez que la decisión estaba tomada y habiendo analizado varias de las páginas del punto 1 había que profundizar con cual quedarse.

El estudio fue fácil o más sencillo que la elección de componentes propios o no. Como se quería algo que valiese para cualquier plataforma ya se descartaron muchas de ellas quedando Telerik y Component One.

El segundo requisito que nos entregaran los fuentes la cual cumplían ambas.

El tercero el número de componentes y funcionalidades en donde claramente Telerik tiene más funcionalidades.

El cuarto otras funcionalidades y plataformas, en este caso Component One tiene unos scaffolding bastante buenos mientras que Telerik te proporciona herramientas de Testing, debug, incluso gestión aunque ahora ya está descatalogada.

Elección final: Telerik.

La realidad es que en general estamos contentos con la elección aunque nunca se ha utilizado las herramientas de testing, debug, el de formación para utilizar componentes y funcionalidades nuevas ya no deja para más, espero utilizarlas algún día.

De documentación está bastante bien y tienen tres grandes versiones al año donde aparecen nuevas funcionalidades de cada plataforma y corrigen errores.

Por otra parte su servicio de soporte para ayudarte solicita casi siempre un ejemplo y hay que hacer mini aplicación. Me imagino que esto dependerá de la licencia que se compre.

#Componentes #VisualStudio #Telerik #ComponentOne #Objetos