Arquitectura en .NET

C

CodE07 #1 Feb '12

Seguro que a todos los que trabajáis de programadores desde hace tiempo os ha pasado la misma idea por la cabeza: "Si pudiera volver a empezar el proyecto en el que trabajo o si empezara un nuevo proyecto, con mi experiencia ahora haría esto así y asá..."

Bien, a todos los que tenéis experiencia en .NET os lanzo la siguiente pregunta:
Si pudiérais empezar de 0 un proyecto de aplicación escritorio, pongamos un ERP escalable con un esquema básico pero que tuviera que incorporar en el futuro módulos distintos en función de las necesidades de cada cliente,
¿Qué arquitectura seguiríais?
¿Cómo abordaríais la capa de datos?
¿Qué motor de base de datos elegiríais?
¿VB o C#?
¿Cómo le sacarías partido a la POO en .NET?
¿Cómo conseguiríais una IU dinámica y bien comunicada con la lógica pero con un nivel alto de desacoplamiento?
¿Cómo gestionaríais los ensamblados y sus versiones?
...
...
...

Las preguntas son por poner algo. Se aceptan ideas de todo tipo. Desde el aspecto más concreto al más genérico.

elkaoD #2 Feb '12

Pero nos darás algo de lo que te paguen, ¿no?

Igualmente, luego posteo algunas de las ideas, aunque un ERP es de lo más jodido que hay (la gestión en general es verdaderamente complicada) sobre todo si lo quieres hacer modular.

1 respuesta

C

CodE07 #3 Feb '12

#2, yo comparto el conocimiento. ¿No hay mejor riqueza que esa? xD

Efectivamente, la modularidad es la que me preocupa. Actualmente tenemos un software propio (me reservo el nombre de la empresa y el nombre del producto) que tiene ya 10 años y que es un éxito en su sector. Sin embargo está fabricado en una herramienta (la cual también me reservo citar) cuyas posibilidades de futuro son nulas. Las hemos estirado al máximo. Yo soy el responsable de innovación del producto. Y, modestia aparte, nos ha ido muy bien puesto que en la mierda de herramienta que está fabricado soy el amo. Si la ves funcionar parece que está hecha en .NET como mínimo (gracias Codejock!!!!!) por lo que a IU se refiere.

Yo trabajé en .NET desde 2005 a 2007 para justamente migrar un software hecho en la misma herramienta de mierda a .NET. Fue un fracaso por la forma que tuvieron de plantear la migración. En vez de hacer un producto nuevo quisieron que convivieran a la par. Y yo, que conocía bien la herramienta vieja y obsoleta en la que estaba programado, avisé del fracaso (me hizo ganar puntos con los directivos de la empresa cuando se cumplió xDDD).

El caso es que para Septiembre voy a tener la oportunidad de iniciar un nuevo proyecto paralelo como Team Leader para desarrollar una aplicación que replique las funcionalidades del producto actual pero fabricada en .NET. Tengo casi claro que usaré WPF (aun así acepto consejos, por favor!!). Pero reconozco que hace años que no trabajo con productos de Microsoft y que la última vez que lo hice, yo era un mero analista programador y los jefes de proyecto no tenían idea de .NET. Con lo cual no quiero que se repita la historia. Y ya que empieza uno de cero, lo suyo es no dar ningún paso en falso. El know how lo tengo y de sobra, pero la experiencia en .NET no tanta :S

Espero ansioso vuestros consejos y sobre todo la experiencia en las cagadas que hayáis o hayan cometido a vuestro alrededor gente que ha trabajado en .NET. Se aprende más de las historias de fracaso que de las éxito.

Es más, aunque salvaguarde cierta privacidad, iré compartiendo los avances con los interesados que trabajen actualmente en .NET.

Gracias!

NeV3rKilL #4 Feb '12 :psyduck:

Yo el único consejo que puedo darte es que C# > VB. Actualmente se lleva más y prácticamente toda la doc, a parte de la de msdn, que puedas encontrar los ejemplos y librerías los suelen tener en c# antes que en vb.

Tampoco programo en escritorio, me dedico al asp, así que no soy ningún experto en el tema.

m0rG #5 Feb '12

Yo tengo muy poca experiencia en .NET pero en mi empresa han hecho un par de proyectos utilizando la arquitectura en N capas. En ese libro se describe una arquitectura enfocada a desacoplar al máximo las diferentes capas del sistema y está basado exclusivamente en .NET. Se basa principalmente en patrones de diseño y trata temas como ORM,LINQ,inyección de dependencias,etc...Hay también una aplicación de ejemplo con diferentes interfaces (Silverlight,escritorio,etc...).

2 respuestas

B

[Borrado] #6 Feb '12

#1 no estaremos hablando de nuestro amigo COBOLverdad?

2 respuestas

Gollumiko #7 Feb '12

Tengo muy poca experiencia por no decir nula, el año pasado acabé la carrera de ingeniería informática y este año estoy haciendo un máster de desarrollo en el que ahora mismo estamos dando un módulo de .NET.

Los profesores que hemos tenido nos han recomendado muchísimo que para el proyecto de fin de máster, así como en futuros proyectos tuviesemos bien presente la arquitectura en N capas que menciona #5. En el link que te ha ofrecido tienes un enlace a un proyecto de ejemplo muy bueno que sirve para tener una visión practica de este tipo de arquitectura.

1 respuesta

C

CodE07 #8 Feb '12

#6, no, tan viejo y obsoleto como Cobol no es el IDE donde programo. Pero sólo permite incorporar ActiveX (COM) y no los nuevos componentes para .NET. Además, tiene un motor de base de datos nativo que en su momento era la leche pero que ya se ha quedado obsoleto y que sólo maneja un SQL ANSI estándar, sin procedimientos almacenados y demás herramientas (el modo transaccional es un show).

#5, #7, gracias por el link. Obviamente usaré las capas de rigor. Es ahora en el entorno actual y cuando puedo voy desacoplando la IU de las consultas SQL sobre todo cuando se trata de clases aisladas encargadas de enviar emails o sms.

Está claro que usaré capas, pero mis dudas van más allá respecto a cómo usarlas bien en .NET. Por ejemplo, estoy en contra de la corriente del no-SQL actual y no quiero que la capa de datos sea de ese estilo en el que llega un momento que uno pierde el control de la instrucción SQL, es decir, tiene que montar un pifostio para una simple update. Es un proyecto que requiere de una agilidad máxima por parte de los desarrolladores. No podemos ponernos muy académicos pero tampoco quiero llenar el código de cochinadas. De hecho los dos últimos años me he pasado gran parte del tiempo en el proyecto actual refactorizando código antiguo y escribiendo clases como Dios manda. Ahora es cuando se recogen los frutos.

Me interesa más la arquitectura "física" de los ensamblados. Aunque para eso hay un departamento técnico que tendrá que estudiar también el tema. La cuestión es que se trata de un proyecto donde constantamente hay que actualizar "módulos" específicos para clientes que se apoyan en otros genéricos. De ahí mi preocupación por la estructura física de los ensamblados. Es una parte que todavía se me escapa en .NET cómo es la mejor forma de hacerlo.

1 respuesta

B

[Borrado] #9 Feb '12

#8 NOSQL solo se usa en determinadas situaciones, por ejemplo en mi caso acceso a varias tablas con más de 10 millones de registros actuales y una estimación de crecimiento que se dispara. En esos casos da igual lo optimizada que tengas una base de datos relacional que tendrás un cuello de botella. Para una aplicación de escritorio ni te lo plantees usar pues no tiene sentido.

elkaoD #10 Feb '12

#6 yo había pensado en CLIPPER o VB6 xD

1 respuesta

B

[Borrado] #11 Feb '12

#10 clipper era mi segunda opción , por lo de "solo se usarlo yo".

C

CodE07 #12 Mar '12

Reabro el hilo para comentar mis comeduras de tarro.

He empezado por empollarme las opciones que tengo con la capa de datos. El equipo de desarrollo de mi empresa asi como el software que tenemos desarrollado, es el típico que no separa la IU de la inexistente capa de datos. Si bien es cierto que por la naturaleza de la aplicación, hacemos uso de complejas consultas SQL (y bastante bien optimizadas, por cierto. Consultas que enlazan 4 tablas, algunas de ellas con 3-4 millones de registros y salen cagando leches).

El caso es que quiero montar una buena capa de datos que permita trabajar "a la antigua usanza", pero que también tenga ciertos DAO sobre tablas importantes.

Empiezas a leer por internet y ahora que si el LINQ to SQL, que si los ORM puros, los ORM más permisivos, etc. Tengo un cacao maravillao en la cabeza que ya no sé como leches abordar la capa de datos.

También es cierto que quiero tal nivel de perfección que es imposible en este, nuestro "oficio".

Por otro lado, la nueva versión será en .NET, pero mi jefe pasa de MSSQL y se inclina por MySQL. ¿Habéis tenido alguna experiencia en MySQL en .NET? ¿Qué tal de rendimiento? ¿Cómo abordáis la capa de datos en vuestros proyectos?

Como dije al principio del hilo, se aceptan sugerencias! xD

Thx!

Usuarios habituales