Cuando comencé a trabajar con .NET Framework 3.5 (versión de lenguaje 3.0) hace 10 años, para mí su funcionalidad era extremadamente limitada, ya que comencé con SharePoint 2010. Estudiando gradualmente una gama más amplia de tecnologías y siguiendo el desarrollo de .NET, I Puedo notar su gran crecimiento de un competidor dudoso a Java a una plataforma cruzada genial con la capacidad de desarrollar demonios para Linux (y estaba destinado exclusivamente para Windows). Por supuesto, cuando encontré la tecnología por primera vez, parecía que todo era suficiente: después de todo, había formas de implementar lo que se pretendía. Pero ahora, teniendo experiencia trabajando en diferentes plataformas y sus diferentes versiones, ya podemos especular que la vida fue un dolor en esos tiempos lejanos.
En general, si es interesante volver mentalmente a esa época y reflexionar juntos en .NET en el contexto de "Fue - se ha convertido", entonces los invito a que participen. Creo que será interesante tanto para quienes codifican recientemente y no conocen las características de las versiones anteriores, como para quienes desean disfrutar de la nostalgia.
Edad del dolor
Cuando comencé a desarrollar, SharePoint 2010 funcionaba en .NET Framework 3.5 y ya incluía mucho: apareció LINQ y había AJAX primitivo. Pero estaba muy limitado por la plataforma, ya que era bastante difícil expandirlo, y simplemente no había herramientas adecuadas en ese momento.
Pain 1: Creando una sola aplicaciónLuego, la tecnología para desarrollar elementos web para la "bola" se basó en WebForms, y cada elemento web era esencialmente una aplicación separada. Personalmente, no era realista para mí hacer una sola aplicación como esta, porque al desarrollar el elemento web, cada uno de ellos inicializa su propio contexto para conectarse a la base de datos; resulta que era imposible hacer un solo contexto. Bueno, por ejemplo, para mostrar datos de la base de datos en las páginas, utilicé SqlDataSource (conectándome a la base de datos por separado en el widget), y para conectarme a 3-4 tablas, tenía 3-4 DataSource en el widget, que, por supuesto , influyó en la velocidad de carga de la página. Para ese momento, ADO.NET Entity Framework ya había aparecido, pero era inconveniente usarlo en SharePoint hasta la versión 4.1, porque Hubo problemas con la interacción de los productos.
Dolor 2: Inaccesibilidad de soporte y patronesLos elementos web para SP 2010 escribimos sobre la tecnología de creación de elementos web SP 2007, porque no hubo plantillas o soporte para el estudio 2008. Poco a poco, con el lanzamiento de Visual Studio 2010, aparecieron sus plantillas, y se hizo más fácil trabajar: fue posible hacer definiciones de listas y codificarlas desde el estudio, para crear una plantilla de sitio web (codificar el tipo de contenido deseado y la descripción de la lista). Anteriormente, todo esto se hacía a través de la edición manual de archivos XML, y esto, sin duda, era un dolor para aquellos que solo estaban inmersos en el desarrollo de .NET, porque la persona no entendía qué tipo de archivo estaba corrigiendo y con qué propósito, pero se centró solo en Las palabras del tío del foro.
Dolor 3: asincronía ...En .NET Framework 3.5 no había asincronía ¬¬ en la forma en que la conocemos ahora, y tuvimos que ejecutar cierto código en otro hilo, comunicarnos a través de controladores delegados, y en WinForms fue posible usar el fondo de un trabajador (es decir, el segundo proceso corriendo en paralelo en el que se realizó el trabajo). Resulta que existía la programación de aplicaciones asincrónicas, pero su implementación fue más allá de la comprensión de junio.
En .NET Framework 4, apareció la Biblioteca de tareas paralelas y, por lo tanto, también aparecieron tareas, es decir, no pudimos declarar delegados, pero hacemos una tarea, pasándole acción y ejecutándola en un hilo paralelo, conociendo el estado / estado y, cuando es necesario, recibimos una señal sobre su implementación. Fue un avance para el desarrollo paralelo, cuando se necesita procesar una gran cantidad de datos, porque antes se hacía con una barra de entrada mayor.
... y ventanas congeladasDebe comprender que la web es muy diferente del desarrollo de aplicaciones de consola (aquí nos referimos a la nomenclatura global, sino a la que usamos al describir las tesis: no específicamente ConsoleApp, sino todas las aplicaciones que se ejecutan en la interfaz del sistema operativo). En una aplicación de consola, todas las operaciones se realizan de forma síncrona de manera predeterminada, y si hay un largo tiempo de procesamiento, la interfaz se "congelará" como si la aplicación estuviera congelada. Para no sentir que el programa no responde, realizamos todas las operaciones en un hilo separado e ingresamos barras de progreso: de esta manera, el usuario vio la actividad de la aplicación, y fue posible controlar desde otro hilo a través de un delegado, por ejemplo.
Dolor 4: Se acerca el despliegueTambién en .NET Framework 3.5 había otra tecnología dolorosa: MS AJAX. El contenido de UpdatePanel se actualizó desde el back-end, mientras que todo lo demás no se reconstruyó en absoluto. En SharePoint, trabajó muy torcidamente debido a los detalles de la inicialización de controles en el ciclo de vida de la página. Aquí funcionó para nosotros después de la primera devolución de datos (a veces después de la segunda), y en general fue difícil hacer que MS AJAX funcionara bien la primera vez, aunque se usó de manera bastante simple con WebForm UpdatePannel limpio. Y no era posible usar AJAX clásico (XMLHttpRequest) en esa versión de la "bola", porque para cada acción era necesario escribir un controlador separado en la parte posterior y colgarlos en un paquete de cada elemento web. Al mismo tiempo, no siempre fue posible liquidar esta funcionalidad.
Cuando en paralelo trabajé con otras aplicaciones escritas en WebForms para tareas "cercanas a la pelota", me sorprendió que el problema de implementar un proyecto en SP es un problema solo para SP. El resto de las aplicaciones se inicializaron en este momento: la ventana se cargó y funciona (¡magia!). En el globo, el despliegue tomó de 2 a 3 minutos, y usted está en un ciclo constante:
En general, todos entendieron que fue un largo proceso de implementación y mini-descansos. Pero estoy agradecido por este dolor, así que aprendí a generar más código y cometer menos errores en una iteración de desarrollo.
Pain 5: Windows y nada más que WindowsEn ese momento, .NET todavía se posicionó como una plataforma de desarrollo para Windows. Sí, hubo un proyecto Mono, que, en esencia, era una "bicicleta" de .NET en Linux, pero era una versión alternativa del Framework principal, y todavía estaba en la página del proyecto
www.mono-project.com/docs/ acerca de mono / compatibilidad ) enumera las características que la versión de Framework no le agrega. Cuando desarrolló algo para Linux, estaba lejos de ser fácil de usar, ya que Mono no tenía ese soporte y comunidad, y si recurría a algunas cosas no realizadas, entonces el código simplemente podría romperse. Es decir, si no lo desarrolla inicialmente para Mono, en principio no puede escribir código independiente de la plataforma. No excluyo la importancia de este proyecto para el desarrollo de .NET en su conjunto, porque sin él Core no habría aparecido, pero personalmente, no tenía ninguna experiencia de combate con él.
Age of Pros (analgésico)El uso mismo de la última versión pura de .NET en sus proyectos elimina casi todos estos problemas. Hay muchas ventajas en el Marco ahora, pero luego hablaremos sobre las ventajas de vincular a Core, como Trabajé con el.
Plus 1: rendimientoCuando apareció .NET Core, se hizo posible realizar operaciones familiares mucho más frescas y rápidas. Las aplicaciones finales en él funcionan de acuerdo con algunos datos hasta 5000 veces más rápido que sus contrapartes en .NET Framework. Pero la compilación y el lanzamiento a veces toman más tiempo: "aproveche durante mucho tiempo, conduzca rápido".
Plus 2: multiplataformaLa principal ventaja de .NET Core es el hecho de que el código escrito funciona simultáneamente en Windows, Linux y Mac. En este caso, puede escribir una aplicación en la arquitectura de microservicio del servicio de registro asíncrono a través de la cola de mensajes. Recuerdo cómo yo, un desarrollador que escribe principalmente en Windows, escribí demonios (servicios) en Linux, y trabajaron de manera estable, rápida y la primera vez, y todo el sistema funcionó en conjunto: en la aplicación, el servicio API y la cola de mensajes en sí. ¡Es solo espacio, cuando escribe en su idioma habitual en una plataforma que no fue diseñada originalmente para este sistema operativo!
Plus 3: asíncrono de todoAhora es posible escribir el respaldo no en paralelo, no multiproceso, sino completamente asíncrono (!), Lo que le permite eliminar tareas individuales de la secuencia principal en métodos asincrónicos especiales o bloques de código. Esto, a su vez, le permite escribir código hermoso y limpio que carece de construcciones voluminosas: es fácil de entender, los métodos asincrónicos se escriben como sincrónicos y funcionan como deberían.
Plus 4: descarga de bibliotecas y consumo de memoria menos intensoSi miras la octava versión actual de C #, entonces tiene mucha azúcar y los cambios son fascinantes. En primer lugar, antes no teníamos la capacidad de descargar dinámicamente la DLL inicialmente descargada (cargamos dinámicamente las bibliotecas en el proyecto, pero permanecieron colgadas en la memoria). Con el lanzamiento de 3rd Core, se hizo posible cargar y descargar dinámicamente bibliotecas según los objetivos. Por ejemplo, si queremos hacer una aplicación de búsqueda de archivos, y el usuario selecciona la extensión XML, cargamos dinámicamente el analizador XML para documentos y buscamos en su árbol. Si queremos buscar por JSON, entonces comenzamos a buscar por su cuerpo, bibliotecas que dependen de ciertas condiciones, y no hay necesidad de mantenerlas en la RAM. Y si. La aplicación ha dejado de consumir constantemente memoria. Cuando descargamos el ensamblaje, liberamos todos los recursos que se aferran a este ensamblaje.
Plus 5: tuplasEl lenguaje aún es joven, vibrante y en desarrollo activo. La última versión agregó muchas cosas interesantes: por ejemplo, las tuplas son un tema activo. Sí, había tuplas antes, pero como una clase separada, que incluía muchos elementos. Ahora se ha transformado en tuplas, cuando podemos crear un método que devuelve no 1 objeto, sino varios. Anteriormente, para devolver más de 1 parámetro, era necesario declarar un parámetro de salida / referencia, o inventar una clase separada y arrastrarlo más, pero ahora puede devolverlo como una tupla.
Para resumir!Muchos desarrolladores tienen esa actitud hacia los cambios de idioma: hasta que no estuvimos bien, no sabíamos qué era malo. .NET Core es de código abierto, por lo que cualquiera puede agregar una función por sí mismo y escribir sobre su dolor en el portal. Por supuesto, hay muchos temas controvertidos: alguien está esperando cambios que parecen completamente incómodos para los demás. Por ejemplo, la versión 8 del lenguaje incluye el control de los tipos de referencia anulables, y hasta ahora la cuestión de la conveniencia es controvertida: la innovación se anunció en 2 versiones anteriores, y se incluyó solo en el Core 3.0 final, y por defecto esta función está desactivada, ya que su inclusión puede conducir a al desglose de un gran proyecto. Pero al escribir una aplicación desde cero, es extremadamente útil y le permite hacer que la aplicación sea más limpia y transparente.
En mi opinión, la plataforma que ahora es un jugador fuerte en el mundo del desarrollo con un umbral de entrada bastante bajo (incluso es más bajo, pero trabajar en ellos es más difícil). Por supuesto, elegir una plataforma significa trabajar con una serie de factores y depender de los objetivos. Si esta es una aplicación compleja que procesa terabytes de datos y necesita ser verificada antes del byte, entonces esta es una programación complicada en las ventajas. Pero debe comprender que esto es medio año para el desarrollo y dos para la revisión, y para cuando se lance, quedará obsoleto. Además, no hay muchas personas que codifiquen las ventajas. Si hablamos de desarrollo empresarial, cuando el tiempo de lanzamiento es de 2 semanas, entonces tiene sentido elegir otra tecnología que ayude a obtener el resultado final más rápido (Java, .NET, php).