lunes, 13 de febrero de 2017
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-).NET
- Qué debe saber un desarrollador .NET en 2017
CampusMVP - When a disk cache performs better than an in-memory cache (befriending the .NET GC)
Dan Roberts - C#7: Better Performance with Ref Locals, and Ref and Async Returns
Jeff Yates - The week in .NET – On .NET on Docker and new Core tooling, Benchmark.NET, Magicka
Bertrand Le Roy - The 68 things the CLR does before executing a single line of your code
Matt Warren - What are non generic collections in C#?
Sanskriti - Caching for Non-Web Applications – Part 1
Paul D. Sheriff
martes, 7 de febrero de 2017
Durante el proceso de negociación de contenidos en un API desarrollado con ASP.NET Core MVC, lo habitual es que el output formatter utilizado para componer el resultado enviado de vuelta al cliente sea seleccionado a partir de lo indicado por el cliente en la cabecera Accept de la petición HTTP, pero en este post vamos a ver que esto no tiene por qué ser necesariamente así.Por ejemplo, supongamos que tenemos una aplicación MVC con un controlador que expone un servicio como el siguiente:
[Route("api/contacts")]
public class ContactsController : Controller
{
private readonly IContactRepository _repository;
public ContactsController(IContactRepository repository)
{
_repository = repository;
}
[HttpGet("{id}")]
public IActionResult Get(int id)
{
var contact = _repository.Get(id);
if (contact == null)
return NotFound();
return Ok(contact);
}
}
Esta acción, que retornaría un objeto de tipo Contact del modelo de nuestra aplicación, podría ser fácilmente utilizada desde otras capas o sistemas, por ejemplo como sigue:// Petición:
GET http://localhost:2805/api/contacts/1 HTTP/1.1
Accept: application/json
// Respuesta:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 51
{"id":1,"name":"John Smith","phone":"998-12-32-12"}
lunes, 6 de febrero de 2017
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-).NET
- The .NET Language Strategy
Mads Torgersen - C#7: Local Functions
Jeff Yates - Pattern Matching in C# 7.0 Case Blocks
Tim Patrick - Typemock o cómo mockear como un campeón.
Leo Micheloni - When Is Easter?
John Simmons - Dissecting the new() constraint in C#: a perfect example of a leaky abstraction
Sergey Teplyakov - The week in .NET – On .NET on public speaking, ndepend, CrazyCore, The Perils of Man
Bertrand Le Roy - Creating a portable and embedded Chocolatey Package
Rick Strahl - Application Insights telemetry processors
Maarten Balliauw - Build Your Own ASP.NET Cache with WeakReferences
Peter Vogel - Get Started with Unit Testing – using xUnit and Moq
Rushfive - Short-circuit Evaluation in C#
Shamseer K.
martes, 31 de enero de 2017
Hace unos días hablábamos de que próximamente veremos cambios en los archivos de proyecto de las aplicaciones .NET Core, que dejarán de utilizar el popular project.json para volver al tradicional .csproj, aunque rejuvenecido y potenciado para hacerlo más versátil y utilizable en los nuevos entornos.Para los que ya hemos comenzado a crear aplicaciones y bibliotecas ASP.NET Core, este cambio implica que en algún momento deberemos actualizarlas al nuevo formato de proyectos. Y como ya adelantamos, este proceso no va a resultar especialmente doloroso aunque obviamente tendremos que saber cómo hacerlo.
En este post vamos a tratar tres posibles escenarios de actualización:
Hey, pero antes de continuar, el tradicional disclaimer: tened en cuenta que tanto Visual Studio 2017 como el tooling de .NET Core está aún en preview, así que hay cosas que podrían variar en el futuro próximo.
lunes, 30 de enero de 2017
Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-).NET
- How do .NET delegates work?
Matt Warren - C#7: Pattern Matching
Jeff Yates - The week in .NET – Adafruit Class Library for Windows IoT Core, Floor Plan
Bertrand Le Roy - Anybody want a gently used StructureMap?
Jeremy Miller - Iterators in C#: yield, IEnumerable & IEnumerator
Alan Zucconi - Multi-threading in C#: Back to Basics (Part 1 of N)
Jon McKee - Cloning Objects in .NET Framework Part II
Juan Francisco Morales - Task.Run vs. Task.Factory.StartNew Part 1 & Part II
Bnaya Eshet - Equality Operator (==) and Value Types in C#
Ehsan Sajjad
martes, 24 de enero de 2017
Probablemente muchos recordaréis que cuando comenzaron a verse las primeras previews de ASP.NET Core, por entonces aún llamado ASP.NET vNext, una de las novedades más sorprendentes que pudimos descubrir fue la aparición de un nuevo archivo de proyecto, llamado project.json, que sustituiría al vetusto .csproj (o vbproj).La comunidad se entusiasmó bastante con la idea porque el nuevo archivo de proyecto era bastante más simple y liviano que el tradicional .csproj, daría menos problemas con los sistemas de control de código fuente, era fácil de leer y de editar sin necesidad de disponer de Visual Studio o un IDE completo, y por tanto era muy portable entre plataformas. Y encima usaba el formato JSON, que sin duda resultaba mucho más cool que XML. ¿Qué más podíamos pedir?
Antes de continuar, permitidme un inciso: aunque conceptualmente todo lo que vamos a contar es cierto en este momento (enero/2017) y probablemente seguirá siéndolo, el tooling aún está en desarrollo y, por tanto, algunos detalles todavía podrían cambiar.
