El Blog de Pedro Hurtado

Avanzamos de Sql Inyection a SSJS(server Side javascript-inyection)

2012-11-21T15:26:45Z

De esos días que a uno le quedan ganas de pasarse por el foro de c# veo esta pregunta y sus respectivas respuestas y ante eso reacciono e intenta evitar situaciones comprometidas.

Resultado como se puede ver ni *** caso:). Vamos a ver si lo convencemos.

http://social.msdn.microsoft.com/Forums/es-ES/vcses/thread/55061187-d5ca-4d01-b5f6-6b6c9bd7ab86

Pero para ello, no lo voy a hacer con Sql Server, Oracle, My Sql,etc. Lo vamos a hacer con Mongo y pronto podréis observar como bien dicen que no todo lo que reluce es oro.

Lo digo por estas cosas que se pueden leer acerca de Mongo y bb.dd no Sql.

-No Sql Inyection

-No Join

-No schemas

Efectivamente toda una maravilla, excepto que como a todos siempre se nos olvida algo. Y es entonces cuando crean una bonita sentencia que no es otra $exists. Lo mismo la crearon por aquello de no tener shemas y podamos hacer query de aquellos documentos que no contiene tal campo, pero claro también podemos hacer query de todos los campos de un formulario donde $exists es verdadero y es aquí donde empieza la fiesta.

Pasitos.

Vamos a ser modernos y además de mongo hoy nos toca todo con Node. Con .Net y c# no tienes este problema, excepto … y ya lo contaré al final.

1. Creamos una carpeta llamada “nodemongo”. Tenemos node y mongodb instalado a jugar si no es así ya sabes Node y Mongo

2. instalamos express para ello sencillo “npm install express”

3. instalamos jade. Una joyita y de las buenas(Me parece buenísimo). “npm install jade”

4. instalamos mongo para node js “npm install mongodb”

5. ejecutamos la siguiente sentencia desde nuestra carpeta “express”

6. Esto nos va a crear una estructura de directorios con vistas,controladores(routes) y public(css y javascript). Es decir todo el esqueleto básico de una app con express.

7. Como somos tan chulos y no hacemos caso a aquello de utiliza estándares nos creamos una tabla(collection) en mongo db para almacenar nuestros login.

desde mongo ejecutamos lo siguiente.

db.login.insert({user:’admin’,password:’123456’})

Si posteriormente ejecutamos db.login.find() podemos ver que nos hemos ahorrado un montón de cosas.

-Create Table

-Insert

-etc,etc

Es decir lo acabas de comprar. Todo en uno y barato:)

Bueno llegado a este punto ya tenemos la suficiente infraestructura para modificar todo aquello que nos aporta express y no es más que modificar una vista para que solicite el login a nuestro sitio y otra página que nos dirá “estás conectado” o “me quieres engañar”.

8. En las vista vamos a index.jade y la dejamos de la siguiente forma.

extends layout

block content
    h1
    p Welcome
    form(action="/users",method='post')
        input(type="text",name="user")
        br
        input(type="text",name="password")
        br
        input(type="submit",value="submit")

9. Modificamos el archivo app.js creado en los puntos 5 y 6 y lo dejamos de esta forma.


/**
 * Module dependencies.
 */

var express = require('express')
  , routes = require('./routes')
  , user = require('./routes/user')
  , http = require('http')
  , path = require('path');

var app = express();

app.configure(function(){
  app.set('port', process.env.PORT || 3000);
  app.set('views', __dirname + '/views');
  app.set('view engine', 'jade');
  app.use(express.favicon());
  app.use(express.logger('dev'));
  app.use(express.bodyParser());
  app.use(express.methodOverride());
  app.use(app.router);
  app.use(express.static(path.join(__dirname, 'public')));
});

app.configure('development', function(){
  app.use(express.errorHandler());
});

app.get('/', routes.index);
app.post('/users', user.list);

http.createServer(app).listen(app.get('port'), function(){
  console.log("Express server listening on port " + app.get('port'));
});

Nuestra app responde a “/” para mostrar nuestro formulario y un post en “/users” para recoger los datos de autenticación.

10. Modificamos en la carpeta “routes” el archivo “users.js” y lo dejamos de la siguiente forma. Ahora entra mongo a realizar sus buenas labores(salvarnos de los join, será que no sabes como funcionan.


/*
 * GET users listing.
 */

exports.list = function(req, res){
    var query = {'user':req.body.user,password:req.body.password};

    var mongo = require('../node_modules/mongodb/index.js'),
        Server = mongo.Server,
        Db = mongo.Db;

    var server = new Server('localhost',27017,{safe:false});
    var db = new Db('test', server);

    db.open(function(err, db) {
        if(!err) {
            db.collection('login', function(err, collection) {
                    collection.find(query).toArray(function(err, items) {
                        if(items.length)
                            res.send("conectado");
                        else
                            res.send("me estás engañando");
                    }
                );

            });
        }
    });
};

Bueno con estos pasos tenemos nuestro sistema preparado para hacer login, fácil no?

11. Ahora con esa maravilla que es node vamos a ejecutar lo siguiente.

node app.js

12. Desde el explorador tecleamos la siguiente url.

localhost:3000

13. Este es el número que me gusta. Jo tenemos un formulario para hacer login y una bb.dd con dos patadas. Esto es una maravilla!!!.

Bueno ahora toca ser malo y vamos a hacer lo siguiente.

1. Lo primero que vemos es una página fea, pero no os preocupéis que después llega el diseñador y todo arreglado.

2. Lo primero es conocer que hace esto . Sencillo tecleamos en usuario “admin” y en password lo mismo por si tenemos suerte. El resultado es evidente.

“me estás engañando”. Bien!!!!

3. Ahora vamos a ver que ha pasado entre bastidores, para ello F12 y developer tool->Network.

El form data deja claro que hay dos campos uno llamado “user” y el otro “password”, nada fuera de lo normal.

4. Vamos a putear….

Lo más sencillo del mundo no comprobar que nuestro usuario y password es el mismo que nos pasan, es mas optimo hacer count(*) .

if(items.length)
   res.send("conectado");
else
   res.send("me estás engañando");

5. Vamos a cambiar de ventana en las dev tools y nos vamos a elements el objetivo no es otro que dejar nuestro html de la siguiente forma.

Algo sencillo cambiar el name del input user por user[$exists] y lo mismo con password para dejarlo como password[$exists]. Seguro que si lo dejo de esta forma alguno puede llegar hasta este punto y pensar que le estoy tomando el pelo, Nooooo!!!.

Es bastante más sencillo que teclear todo lo que nos dice esta pagina de las 1000 que hay por internet http://www.unixwiz.net/techtips/sql-injection.html y además se ha pasado de moda:). Es más sencillo teclear lo siguiente, sabes que? no te lo imaginas a estas alturas:). De lo más sencillo.

- En el campo user tecleamos “true”

- En el campo password tecleamos “true”.

Si al final lo que queremos es que exista el campo “user” y el campo “password” en nuestra collection(tabla), menuda maravilla. La respuesta es clara acabas de pasar de impostor a ser el dueño del mambo.

Quieres ser el señor, pulsa en "submit”.

Conclusiones.

Si alguien está libre que tire la primera piedra a todas estas preguntas.

1. Quien no utiliza los mismos nombres de campos en sus formularios que en la bb.dd, yo diría que todos.

2. Quien no ha montado alguna vez un sistema de login así. Yo diria que todos.

3. Quien no se deja una entrada sin validar. Yo diría que alguna vez todos.

4. Quien ha creado para mongo un anti$exists. Ninguno.

5. Como respuesta a los de c# estáis libres de pecado puesto que vuestro user y password es string (TIPADO) y mongo ante esta query

db.login.finc({user:'{$exists:true}',password:'{$exists:true}'})

Responde con 0 registros( que sacrilegio registros, ¿no deberían ser documentos? y en vez de ORM ODM ). Señores por una vez no somos los inseguros. Excepto que utilices el magnifico $where

6. Quien no ha validado basándose en Count y no hacer comprobaciones posteriores.

7. Podemos ver como cada día que nuestra profesión va en continua evolución hasta encontrar eso “la panacea”.

Node debug. De la desilusión al conformismo

2012-11-15T15:38:00Z

Últimamente se han puesto de moda una serie de tendencias que no se donde nos van a conducir, pero porque no probar.

La verdad que me inspiraron estos post que me encontré del amigo Juanma (@gulnor).

http://blog.koalite.com/2011/12/mas-sobre-el-tutorial-node-js-express-jquery/

Así como ver esto en el build 2012.

Para ello no me plantee grandes cosas sino algo muy concreto quiero depurar el ejemplo que hay en la página de Node el típico “hello world”

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

He dicho claro no quiero hacer el “Hello World” quiero depurarlo. Ya veréis en que se convierte esto.

Primer Intento (Depurar con node).

Antes de empezar os recomiendo esta lectura

http://nodejs.org/api/debugger.html

1. Si no tenéis node instalado lo podéis hacer desde

http://nodejs.org/download/

2. Abrimos el Notepad.

3. Copiamos el código y lo guardamos en una carpeta yo para el ejemplo he creado una con nombre “debugnode”. La extensión del archivo es indiferente un .txt también funciona aunque lo normal es que lo guardes con extensión .js. Te lo dejo a tu elección.

4. Ejecutamos el command prompt de node.

No esperéis grandes cosas, alguno puede intuir que se le va a abrir una bonita pantalla negra como la vida mismo. Y preparados para teclear muchas veces “Ctrl+C” o si te agobias más fácil la cruz roja.

5. Tecleamos el siguiente comando “node debug server.js” y el resultado es la siguiente ventana.

Anda no te quejes que algo de color hay. La verdad que da miedo y la sensación es como de impotencia. Primer “Ctrl+C”. bueno como no vas a romper nada vuelve a entrar si haces lo mismo que yo hice y piensa un poco. Tienes dos caminos uno imprimir la página de la documentación y tenerla siempre a tu derecha. La otra es tener un poco de imaginación e intentar pulsar algo, que te parece “help” o “quit” o de nuevo “Ctrl+c” o bien eso la cruz Roja.

Si llegado a este punto no has cerrado y te has ido a tomar una caña al pulsar “help” te aparece lo siguiente.

Es decir comandos bastante intuitivos y con una gran similitud con el debug de Visual Studio.

Node	Visual Studio
cont o c	F5
next n	F10
step p	F11
SetBreakPoint sb (nº linea)	F9

Al resto le podeís buscar vosotros su pareja en visual studio.

4. Vamos a jugar con algunos comandos

a) pulsamos list() muestra las 6 primeras lineas de código.

b) una vez que vemos todo el código este concretamente tiene 6, imaginemos uno con 2000, menudo sudor frio te puede dar. tecleamos sb(3) y ya tenemos nuestro primer breakpoint, como siempre intuitivo y por eso nos muestra un “*” a la izquierda de linea 3.

c) pulsamos c para que se pueda ejecutar todo el código y podamos invocar nuestro “hello world” desde el explorador.

d) Abrimos en el explorador la siguiente url “http://localhost:1337” y vemos que el explorador se queda dando vueltas y sin responder, no os preocupéis. Estamos en el breakpoint.

e) ahora quiero ver el valor de req. Request para los amigos. sencillo pulsas repl y ya tienes un magnifico entorno para evaluar expresiones.

    Aqui te invito a que ejecutes los siguientes comandos.

    req.headers.

    req.method.

    req.url.

El resultado obtenido es el esperado.

Estamos viendo las cabeceras http el metodo y la url que nos invoca, como podéis observar todo un logro.

Seguro que alguno a estas altura piensa lo mismo que yo y se siente desilusionado con tanto bombo para tan poca cosa o tiene las mismas sensaciones que yo una buena y otra mala.

La buena, por un momento me sentí con 20 años menos en plenos 90 , rejuvenecido con ganas y con una herramienta mejor que la utilizaba entonces que no era otra que poner banderas y compilar, porque ni depurador había. Ves hemos progresado eres más joven y más listo. Ya tienes depurador.

La mala es que me levante de la silla y me fui corriendo al espejo a ver si de verdad tenía 20 años menos y efectivamente estaba en 2012 utilizando algo que ya había utilizado en los 90. De hay mi gran desilusión.

Pero como se puede hablar bien de esto, esa debería haber sido mi siguiente reacción y un helper a la cruz roja, pero como ha tozudo no me gana nadie, me di otra oportunidad.

Segundo Intento (node-inpector).

Buscando por la web me encontré con esta otra herramienta https://github.com/dannycoates/node-inspector.

Bueno piensa que si la gente habla bien de node algo tiene que tener. Vamos a hacer lo siguiente e instalamos node-inspector.

1. Ejecutamos el siguiente comando desde el directorio npm install node-inspector.

npm es un gestor de paquetes de node parecido a nuget.

2. Ejecutamos el siguiente comando.

node --debug server.js y obtenemos el siguiente resultado.

3. Abrimos otra ventana con el command prompt y ejecutamos lo siguiente comando después de lógicamente entrar en el directorio “nodedebug” o en el que hayas creado.

“.\node_modules\.bin\node-inspector &”

El resultado es el siguiente

Bueno y ahora como depuro, pues sencillo lee los mensajes de ambas pantallas y tira de tu imaginación o de alguna que otra búsqueda por internet. Piensa un poco tienes primero un mensaje diciendo que tu servidor esta corriendo en el puerto 1337 por otra parte un mensaje de alguien escuchando en el puerto 5858 y en la última ventana un mensaje que me dice que vaya a la dirección tal y que empezare a hacer debugging.

Pues vamos a hacerle caso.

Abrimos chrome o cualquier explorador webkit(yo solo lo he probado en chrome) y hacemos caso a la pantalla negra que para eso es vieja y sabia. El resultado sería el siguiente.

La primera exclamación es “jo que bueno” si son las developer tool de chrome. No te confundas es una buena pagina web que hace lo mismo o parecido a las devtools. Vamos a verlo para ello podemos pulamos F12 y nos aparecen las verdaderas devtools y ahora para picaros un poquito más quiero que pongáis un breakpoint no en el primer texto que vemos sino en la linea 13 del archivo overrides.js tal y como os muestro.

y ahora un breakpoint en el impostor el resultado es que el legitimo se para en la linea 13 y podemos ver que recibe un mensaje al servidor con el siguiente formato.

"{"id":25,"result":{"breakpointId":"1","locations":[{"lineNumber":2,"columnNumber":6,"scriptId":"23"}]}}"

Ya sabeís a jugar o mejor a estudiar si queréis haceros vuestro propio depurador .

DebuggerProtocol.

El código fuente de esta pagina web no devtool lo tenéis en la carpeta “node_modules\node-inspector\front-end”

Bueno parece que esto mejora, pero si analizamos necesito 4 ventanas para depurar dos negras y otras dos con el explorador chorme que lo mismo no lo quiero instalar y otra con el explorador que utilizas para hacer peticiones. He aprovechado para conciliar a dos rivales IE10 y Chrome todo ello para depurar una app desarrollada en node. Todo un logro por mi parte sentar en la misma mesa a los dos.

Desilusionado pues igual que yo pero un poco menos.

Tercer intento(Microsoft viene a salvarnos).

Ante estas dos frustrantes actuaciones y recordando un poco me vino a la cabeza que webMatrix soportaba node. Pues vamos a ello.

1. Descarga WebMatrix.

2. Desístala iisnode si lo tienes instalado, creo que lo instala webMatrix en algún momento, no estoy seguro.

3. Instala la versión de iisnode desde esta url

https://github.com/tjanczuk/iisnode/downloads

Yo concretamente instale esta para una máquina de 32

https://github.com/downloads/tjanczuk/iisnode/iisnode-iis7express-v0.1.13-x86.msi

Y comprueba si quieres depurar node con el siguiente comando

%localappdata%\iisnode\ existe la carpeta iisnode en la ruta y que en vez de encontrarte con un archivo js te encuentras con una dll llamada iisnode-inspector.dll.

4. Creo que tienes que hacer algún cambio en el archivo applicationhost.config.

%userprofile%\documents\IISExpress\config\applicationhost.config

concretamente este

<section name="handlers" overrideModeDefault="Allow" /> su default value es “Deny”

5. Por último tienes que cambiar el webConfig de las plantillas que trae webMatrix por defecto con lo siguiente.

<configuration>
    <system.webServer>
        <handlers>
            
            <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
        </handlers>
        <rewrite>
            <rules>
                
                <rule name="LogFile" patternSyntax="ECMAScript" stopProcessing="true">
                    <match url="^[a-zA-Z0-9_\-]+\.js\.logs\/\d+\.txt$"/>
                </rule>
                
                <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
                    <match url="^server.js\/debug[\/]?"/>
                </rule>
                
                <rule name="StaticContent">
                    <action type="Rewrite" url="public{REQUEST_URI}"/>
                </rule>
                
                <rule name="DynamicContent">
                    <conditions>
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
                    </conditions>
                    <action type="Rewrite" url="server.js"/>
                </rule>
            </rules>
        </rewrite>
        <iisnode>              
          debuggerPortRange="5058-6058"
          debuggerPathSegment="debug"   
          maxNamedPipeConnectionRetry="3"
          namedPipeConnectionRetryDelay="2000"        
         </iisnode>
    </system.webServer>
    <system.web>
</configuration>
A partir de este momento ya podemos ejecutar y depurar nuestra app node con webMatrix. para ejecutarla simplemente ir al sitio de webMatrix tal y como muestro.

Desde otra ventana del depurador podeís ejecutar la siguiente url y a depurar “http://localhost:33732/server.js/debug/”.

Como podéis ver algo que no te lleva unas pocas horas y es por eso por lo que uno se encuentra al final ya no desilusionado sino conformista, porque aun habiéndolo logrado esto no es ninguna maravilla hemos pasado de 4 a 3 ventanas y un entorno más amigable, pero con deficiencias en Intellisense y demás…

Otras opciones que podéis probar son.

Cloud 9 ide

WebStorm

o incluso el propio eclipse https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Applications-Debugger.

Pero vamos nada parecido a lo que Microsoft podría hacer con Node y que sería integrarlo en Visual Studio.

Conclusiones.

Que tristemente Microsoft apuesta por node porque realmente esta Azure e interesa. Pero veo que el esfuerzo realizado no compensa lo que node me da frente a lo que me da MVC como desarrollador .net aunque es algo que no tenemos que dejar pasar y seguir muy de cerca.

Espero dos cosas.

1. Que Microsoft lo integre en Visual Studio.

2. Que deje node donde esta que como servicio gratuito ya ha hecho creo yo lo que le corresponde. Dar herramientas medianamente decentes. Y que apueste por TypeScript y haga su propio motor con “chakra”.

Estoy soñando o me lo estoy creyendo

Los 4 Jinetes del Apocalipsis

2012-10-30T08:10:00Z

No os preocupéis, que aunque me estoy pasando al lado oscuro aún no he perdido la cabeza, no quiero hablar de “caballo blanco”,”caballo rojo”,”caballo negro” y “caballo bayo”. En esta ocasión voy a hablar de otros 4 jinetes que pueden hacer de nuestro código una apocalipsis. Me refiero concretamente a estos 4 “this”,”call”, ”apply” y “bind” de quien?

De quien va a ser, de mis últimas andadas por “Javascript”. Bueno vamos al grano:).

this: Sobre este hay ríos de tinta, pero voy a intentar explicarlo desde una lógica. Cuando nosotros definimos una función tal como esta.

console.log(window.name);
function foo(name) {
    this.name = name;
}
console.log(window.name);

Y la invocamos como foo(‘window’). Lo que realmente estamos haciendo es llamar a un método que hemos definido en el objeto window (ámbito global) y agregando a este sino lo tiene una propiedad con nombre “name”, no es el caso puesto que window ya posee una propiedad llamada “name”.

En realidad tiene todo el sentido del mundo foo pertenece a window y por tanto this es window. para comprobarlo podéis ejecutar

“foo” in window y devuelve true.

¿Cuándo this es foo ? pues cuando hacemos lo siguiente:

window.name = "window";
function foo(name) {
    this.name = name;
}
var objeto = new foo("mi nombre");
console.log(window.name);
console.log(objeto.name);

La salida en este caso es “window” para window.name y “mi nombre” para “objeto.name”. Lo que hemos hecho no es invocar un método sino crear un objeto del tipo foo y por tanto this es el y no el ámbito global.

Vamos ahora a definir un objeto y vemos que su comportamiento es exactamente el mismo.

objeto = {
    name: "",
    surname: "",
    fullname: function () {
        console.log(this.name + " " + this.surname);
    }
}
objeto.name = "Pedro";
objeto.surname = "Hurtado";
objeto.fullname();

Ya podemos decir que “this” se comporta de la forma esperada “this representa el objeto al que pertenece nuestro método o propiedad” no cambia respecto a lo que estamos acostumbrados.

Pero claro en este fantástico lenguaje “de verdad”, siempre tiene que haber una excepción y la excepción es “this entra en el limbo”.

Vamos con un ejemplo.

window.name = "window";
function foo(name,surname){
    this.name = name;
    this.surname = surname;
    this.fullname = function () {
        function writeFullName() {
            console.log(this.name + " " + this.surname);
        }
        writeFullName();
    }
}

var objeto = new foo("Pedro", "Hurtado");
objeto.fullname();

En este caso alguno puede pensar que la salida por consola será “Pedro Hurtado”, pues no this se fue al limbo y la salida es “window undefined”. Y si antes dijimos que “this representa al objeto al que pertenece el método o propiedad”

¿A quien pertenece WriteFullName?.

Mis ojos me dicen que a nadie es algo raro, esta en el limbo:). Bueno señores ese limbo no es otro que el objeto global “window”.

Y alguien puede decir menuda ….. No por favor!!!. Vienen a salvarnos los otros tres jinetes.

call: Realmente es un método del objeto “Function” si “F” con mayúscula y nos permite invocar a una función pasando en el primer parámetro el ámbito es decir this y en el segundo parámetro una lista de los posibles parámetros separados por comas, yo en este caso no lo estoy utilizando, una de las bondades o maldades del dinamismo .

window.name = "window";
function foo(name,surname){
   this.name = name;
   this.surname = surname;
   this.fullname = function () {
       function writeFullName() {
           console.log(this.name + " " + this.surname);
       }
       writeFullName.call(this);
   }
}
var objeto = new foo("Pedro", "Hurtado");
objeto.fullname();

Ahora si que el resultado es el esperado, por consola la salida será “Pedro Hurtado”.

apply: De este poco que decir una vez explicado que hace call. La única diferencia es que el segundo parámetro se pasa como una array. La verdad que no se cual fue primero si call o apply pero realmente son el mismo perro con distinto collar:).

bind: Tratemos al último jinete este a diferencia call y apply lo que hace es establecer el ámbito y si se quiere los parámetros pero no invoca a la función. Es decir devuelve un objeto que después podemos invocar.

Como podemos observar los metodos “call”, “apply” y “bind” tiene un comportamiento parecido y lo que vienen es a suplir la carencia real de javascript de no tener bien resuelto el funcionamiento de this.

Con lo cual tenemos que tener mucho cuidado con el uso de this en los callback que tan de moda se han puesto. Si por ejemplo observáis código WinJs se puede ver que casi siempre que se ejecuta algún Promise y queremos tratar con this nos encontramos con bind.

Lo que realmente hace falta desde mi punto de vista es ya de una vez, alguna palabra reservada como “class” y su funcionamiento lógicamente implementado. Si las fuentes no me fallan creo que estamos en el camino http://wiki.ecmascript.org/doku.php?id=harmony:classes, pero claro seguro que protected override o alguna otra la dejan para la versión no harmony sino para la versión ecma-apocalypse.

Conclusiones.

De lo más sencillo, evita el uso de this en javascript. No solo te puedes llevar sorpresas sino que además vas a definir variables innecesarias en el ámbito global, si después de esto sigues empeñado en el uso de this, acuérdate de usar si lo necesitas los otros tres jinetes.

Soy asincrono despues de 0 milisegundos

2012-10-18T14:47:00Z

Posiblemente alguno puede seguir pensando que escribir un Promise es hacer su código Javascript asíncrono. Bueno pues si piensas eso ya te digo yo que no.

Promise no es más que un mecanismo para hacer nuestro código más legible y de esa forma evitar los tediosos callback que hasta el momento hemos utilizado.

Bueno como siempre vamos a empezar con un ejemplo para demostrar que Promise no es asíncrono.

function promise() {
    return new WinJS.Promise(function (complete, error, progress) {               
        try {
            var i = 0;
            for (i = 0; i < 10; i++) {
                progress(i);
            }
            complete(i);
        }
        catch (ex) {
            error(ex);
        }         
    });
}
function runPromise() {
    var result = promise().then(
     function (data) {
         console.log(data);
     },
    function (progress) {
        console.log(progress);
    },
    function (error) {
        console.log(error);
    });            

}
runPromise();

Si analizamos este código la respuesta inmediata sería, la salida por consola nos mostrará la siguiente secuencia 0,1,2,3,4,5,6,7,8,9 y por último 10. La respuesta es por consola solamente vamos a ver “10”, es decir la ejecución de complete, pero nunca progress.

Ante esto la pregunta ¿Si progress se ejecuta y no es “undefined”, porque no escribe en la consola el valor de i?. Pues sencillo o creo que más bien complicado:).

Cuando ejecutamos el constructor de una Promise pasan varias cosas.

1. Se pasa al contructor una función anónima que recibe tres parámetros “complete,error,progress” y se ejecuta.

2. Ninguno de los tres parametros apunta en realidad a las funciones que he pasado como parametros a la función then. Puesto que aún no se ha ejecutado, sino a “complete,error,progress” de “PromiseStateMachine” una clase que se crea en base.js de la que deriva “Promise”.

3. ¿Y por qué se ejecuta “complete” y no “progress”? Pues por eso por que Javascript es “single-threaded”. Realmente la línea de código siguiente “complete(i)” no hace lo que creemos , sino asignar un valor “10” al objeto Promise que hemos creado.

4. Bueno ¿Y entonces porque ejecuta lo siguiente?

function (data) {
     console.log(data);
},

Porque al ejecutar “then” después de nuestra función anónima nuestra Promise ha realizado internamente lo suficiente como para que “then” sea un objeto del tipo “CompletePromise” y llama a la función “then” de este, ¿queréis ver el código? :)

try {
// If the value returned from the completion handler is the same as the value
// provided to the completion handler then there is no need for a new promise.
//
var newValue = onComplete ? onComplete(this._value) : this._value;
return newValue === this._value ? this : new CompletePromise(newValue);
} catch (ex) {
return new ExceptionPromise(ex);
}

En la primera linea se ve claramente que se llama a “onComplete”, función que escribe en la consola nuestro famoso “10”. De lo cual podemos deducir que primero se ejecuta nuestro bucle y después “then”, sino os convence podéis cambiar el valor 10 por 100000000 y ya os digo yo que os vais a esperar un poquito o más bien mucho:).

Bueno después de este tedioso rollo, quizá alguien se pregunte para que quiero utilizar Promise, bueno mi conclusión es sencilla como dije nos ayuda a estructurar nuestro código de mejor forma, cosa que no implica que mi código sea asíncrono. Queda claro no:).

Queréis el mismo código asíncrono, entre comillas:), bueno pues otra función anónima que ejecute nuestro bucle pero con “setTimeout”.

function promise() {
   return new WinJS.Promise(function (complete, error, progress) {
       var id;
       id = setTimeout(function () {
           try{
               for (var i = 0; i < 10; i++) {
                   progress(i);
               }
               complete(i);
           }
           catch (ex) {
               error(ex);
           }
           finally {
               if (id) {
                   clearTimeout(id);
               }
           }
       }, 0);
   });
}
function runPromise() {
   promise().then(
       function (data) { console.log(data); },
       function (progress) { console.log(progress); },
       function (error) { console.log(error); }
   );
}
runPromise();

Y a estás alturas alguien puede pensar y porque el titulo de este post, pues porque por casualidades de la vida ayer me encontré con esta otra entrada que es digna de leer y yo paso un 0 a setTiemout:).

setImediate Api

Me tome la molestia de escribir este script y probarlo en Chrome,FireFox e IE9 y la verdad que me sorprendió, bastante que Chrome sea el más lento en ejecutar callback por segundos

var i = 0,
id,
endDate,
startDate = new Date().getTime(),
ckeckEnd = function () {
    endDate = new Date().getTime();
    var result = (endDate - startDate)
    if (result >= 1000) {
        if (id) clearInterval(id)
        console.log(result + " " + i);
        
    }
    else {
        i++;
    }

};           
id = setInterval(function () {
ckeckEnd();
}, 1);

Conclusion:

Que todo esto es un mundo desconocido para los que venimos de c# y que realmente explorarlo es toda una satisfacción, aunque podemos decir que Javascript tiene mucho, pero mucho que mejorar

Ocultar o esconder no es prohibir

2012-10-09T15:21:00Z

Si me pongo a pensar y me traslado al pasado, siempre hable mal de Javascript. Últimamente he cambiado mi actitud pero con peros, es decir es un lenguaje que tiene que mejorar y no poco:).

Revisando WinJS, de esa forma que me gusta a mí. No haciendo el típico ejemplo “Hola Mundo”, sino adentrándome en las profundidades de “base.js” me encuentro con lo siguiente:

function initializeProperties(target, members) {
        var keys = Object.keys(members);
        var properties;
        var i, len;
        for (i = 0, len = keys.length; i < len; i++) {
            var key = keys[i];
            var enumerable = key.charCodeAt(0) !== /*_*/95;
            var member = members[key];
            if (member && typeof member === 'object') {
                if (member.value !== undefined || typeof member.get === 'function' || typeof member.set === 'function') {
                    if (member.enumerable === undefined) {
                        member.enumerable = enumerable;
                    }
                    properties = properties || {};
                    properties[key] = member;
                    continue;
                }
            }
            if (!enumerable) {
                properties = properties || {};
                properties[key] = { value: member, enumerable: enumerable, configurable: true, writable: true }
                continue;
            }
            target[key] = member;
        }
        if (properties) {
            Object.defineProperties(target, properties);
        }
    }

La verdad que tampoco me adentre mucho, puesto que esto te lo encuentras entre las líneas 15 y 46 de base.js.

Lo que más me llamo la atención fue concretamente esta línea

“var enumerable = key.charCodeAt(0)!== /*_*/ 95;

En realidad eso lo que hace es comprobar, como bien podéis ver si el primer carácter de una propiedad empieza por “_” y marcar enumerable como false.

¿Que es enumerable?

Pues sencillo uno de los parametros del objeto que pasamos en el tercer de los parametros a Object.defineProperty. Seguro que alguno se estará preguntado si esto significa que esa propiedad es privada por aquello de “_” , bueno eso no es así. Realmente lo que hace es ocultar esta propiedad a los siguientes métodos, entre otros:

1. Object.Keys(objecto);

2. for (prop in objecto)

Por contra esa propiedad será accesible si accedemos a ella de la siguiente forma:

1. objeto._propiedad.

2. objecto[“_propiedad”]

3. “_propiedad” in objeto devuelve true;

Os paso el siguiente script por si alguien quiere conprobarlo.

var objeto = {};
       Object.defineProperty(objeto, "_propiedad", { value: 10, enumerable: false, writable: true, configurable: true });
       for (var propiedad in objeto) {
           console.log(propiedad);
       }
       objeto["_propiedad"] = 20;
       console.log(objeto["_propiedad"]);
       console.log(objeto._propiedad);
       console.log("_propiedad" in objeto);

Que hace por nosotros Visual Studio a nivel de Intellisense. Pues sencillo ocultar cualquier propiedad de un objeto javascript cuyo nombre empiece por “_”. Eso es bueno, pues para quien lo quiera quizá sí, para mí ya os digo que no, puesto que en el fondo esa propiedad es tan publica como cualquier otra.

De eso es fácil deducir que cualquier objeto creado en WinJS con los métodos

WinJS.Namespace y WinJS.Class expone todas sus propiedades como públicas.

La pregunta a esto es sencilla ¿a quien le gusta esto?.

Como referencias os paso los siguientes link.

http://msdn.microsoft.com/es-es/library/kb6te8d3(v=vs.94).aspx

http://msdn.microsoft.com/es-es/library/hh965578(v=vs.94).aspx

http://kangax.github.com/es5-compat-table/#showold

Veis como Ocultar no es Prohibir .

Desmitificando CodeFirst(2/2) V 4.3

2012-06-29T13:18:27Z

En el anterior post Desmitificando CodeFirst(1/2), me he centrado en la versión 4.2 de Entity Framework y el objetivo de este no es otro que analizar la versión 4.3 y ver realmente que hay en la tabla “dbo.__MigrationHistory”.

Siguiente con el modelo anterior lo primero que tenemos que hacer es activar Migration, pero como no es el objetivo de este post os paso un link para quien no lo conozca y quiera profundizar.

EF 4.3 Automatic Migrations Walkthrough.

El objetivo claro es demostrar dos cosas.

1. Lo que se guarda en la tabla no es un Hash sino un Xml, eso si con aderezo:).

2. Ver lo parco que es EF en la gestión de Exceptions teniendo a mano toda la información para mostrarnos algo más que lo que nos dice.

Vamos con lo primero. Para ello no necesitamos nada más que leer con Ado.Net la tabla “dbo.__MigrationHistory” y descomprimir el contenido de la columna Model.

        1: using (SqlConnection cn = new SqlConnection(@"Tu Conexion"))

       2:  {

       3:      cn.Open();

       4:  

       5:      SqlCommand cmd = new SqlCommand("select top 1 Model from dbo.__MigrationHistory order by CreatedOn desc", cn);

       6:      SqlDataReader rd = cmd.ExecuteReader();

       7:      rd.Read();

       8:      byte[] b = rd[0] as byte[];

       9:  

      10:      using (MemoryStream ms = new MemoryStream(b))

      11:      {

      12:          using (GZipStream stream2 = new GZipStream(ms, CompressionMode.Decompress))

      13:          {

      14:              var Edmx = XDocument.Load(stream2);

      15:              Console.WriteLine(Edmx.ToString());

      16:          }

      17:  

      18:      }    

      19:      

      20:  

      21:  

      22:  }

      23:  

      24:  Console.ReadLine();

Con lo cual si el XDocument lo guardasmos en disco con la extensión edmx y agregamos este al proyecto vemos que es lo que hay en la tabla Migrations.

Ya si nos queda claro que estamos utilizando Xml:)

Vamos a seguir con nuestro querido “InvalidOperationException”. Y concretamente de lo que me quejo es de EF no nos informe de algo más en esta exception, puesto que podría decirnos exactamente que es lo que cambia entre un modelo y otro.

Para ello seguimos con la operación del anterior post y cambiamos la longitud de la propiedad Nombre de 50 a 100 y obtenemos la misma exceptión pero con un mensaje diferente.

Claro lo fácil sería ejecutar los siguiente comandos desde Pakage Manager Console

1. Enable-Migrations.

2. Add-Migration "Salvameporfavor"

3. Update-Database –Verbose.

Y todos felices, pero se puede dar el caso que no me interese modificar la base de datos sino simplemente saber el porque y en consecuencia actuar. Para ello vamos de nuevo con Reflectión y ver que hace internamente EF para mostrarnos esta exceptión. En definitiva lo que hace es comparar el modelo guardado con el modelo generado.

El código para obtener las diferencias es el siguiente y después de mostrarlo vendrás las criticas, eso si constructivas:)

       1: XDocument documentDataBase = null;

       2:  

       3: using (SqlConnection cn = new SqlConnection(@"Tu Cadena de Conexion"))

       4: {

       5:     cn.Open();

       6:  

       7:     SqlCommand cmd = new SqlCommand("select top 1 Model from dbo.__MigrationHistory order by CreatedOn desc", cn);

       8:     SqlDataReader rd = cmd.ExecuteReader();

       9:     rd.Read();

    byte[] b = rd[0] as byte[];

    using (MemoryStream ms = new MemoryStream(b))

    {

        using (GZipStream stream2 = new GZipStream(ms, CompressionMode.Decompress))

        {

            documentDataBase = XDocument.Load(stream2);

        }

  

    }       

  

  

}

  

XDocument documentModel = null;

using (ContextCliente ct = new ContextCliente())

{

    using (MemoryStream stream = new MemoryStream())

    {

        XmlWriterSettings settings = new XmlWriterSettings();

        settings.Indent = true;

        using (XmlWriter writer = XmlWriter.Create(stream, settings))

        {

            EdmxWriter.WriteEdmx(ct, writer);

  

        }

        stream.Position = 0L;

        documentModel = XDocument.Load(stream);

    }

  

  

}

  

  

Assembly a = typeof(DbContext).Assembly;

  

var tipo = a.GetTypes().Where(c => c.FullName == "System.Data.Entity.Migrations.Infrastructure.EdmModelDiffer").FirstOrDefault();

  

var ModelDiffer = Activator.CreateInstance(tipo);

  

var Metodo = ModelDiffer.GetType().GetMethod("Diff");

  

var resultado = Metodo.Invoke(ModelDiffer, new object[] { documentDataBase, documentModel, null });

Si miramos el código estamos llamando al metodo “Diff” de la clase “System.Data.Entity.Migrations.Infrastructure.EdmModelDiffer”. Como no, definida con el modificador de acceso “Internal” :( y este nos devuelve un IEnumerable<MigrationOperation> y en nuestro caso una clase derivada de MigrationOperation con nombre “AlterColumnOperation”, me suena a la migration que queda pendiente de ejecutar en la bb.dd.

Y ahora yo digo en vez de preguntar y devolver bool en el método “ModelMatches” de la clase “InternalContext” por que no se contruye una exception en condiciones diciendo en que difieren ambos modelos, veis como la critica es constructiva:)

ModelMatches de la clase InternalContext".

       1: public virtual bool ModelMatches(XDocument model)

       2: {

       3:     string connectionString = null;

       4:     return !new EdmModelDiffer().Diff(model, this.Owner.GetModel(), connectionString).Any<MigrationOperation>();

       5: }

Pues nada esperemos que alguien piense en ciertas mejoras y que estás nos ayuden a dormir mas felices:)

Desmitificando CodeFirst(1/2)

2012-06-29T11:11:00Z

El día 22 tuve la suerte con @MiguelEgea, de dar una charla en Málaga .NET User Group y una de las cosas que afirme es que la tabla del sistema que se genera con la versión 4.3 “dbo.__MigrationHistory” en su columna “Model” no guarda un Hash sino que realmente es una copia del modelo, es decir un emdx comprimido.

Inmediatamente @pablonete me pone cara de incrédulo y que mejor que demostrarle eso con un post:).

Independientemente de demostrar esto lo primero que quiero desmitificar es que Codefirst utiliza Xml y no poco, en resumen el mismo que las otras dos modalidades DataBaseFirst y ModelFirst.

Lo segundo es que casi todos los que trabajamos con CodeFisrt tarde o temprano recibimos una “InvalidOperationException” tal y como os muestro.

El porque es sencillo tu modelo no coincide con lo que en versión 4.2 tenemos guardado en la tabla “EdmMetadata”.

Y es aquí donde @pablonete si tiene razón en versión 4.2 si se guarda un “Hash” mientras que en 4.3 no.

Vamos a demostrarlo con la versión 4.2.

1. Definimos un modelo sencillo que es valido para el ejemplo.

//Entidad

public class Cliente

{

   public int Id { get; set; }

   public string Nombre { get; set; }

}

//Configuracion de la entidad Cliente

public class ClienteEntityConfiguration : EntityTypeConfiguration<Cliente>

{

   public ClienteEntityConfiguration()

   {

       this.ToTable("Clientes");

       this.HasKey(c => c.Id);

  

       this.Property(c => c.Nombre).HasMaxLength(50).IsRequired();

   }

}

//DbContext

public class ContextCliente : DbContext

{

   protected override void OnModelCreating(DbModelBuilder modelBuilder)

   {

       modelBuilder.Configurations.Add(new ClienteEntityConfiguration());          

  

   }

}

Sí creamos un cliente y posteriormente nos vamos a la bb.dd y ejecutamos “select * from EdmMetadata” el resultado de la consulta es el siguiente.

La forma sencilla de provocar “InvalidOperationException” es cambiar en la clase ClienteEntityConfiguration esta línea

this.Property(c => c.Nombre).HasMaxLength(50).IsRequired();

Por esta otra

this.Property(c => c.Nombre).HasMaxLength(100).IsRequired();

A partir de ese momento nuestro Hash se convierte en lo siguiente.

“0F9CDC01973A8E83D521518166B9F8C37E8D533704219CF1F2DC02B83AEE0F77”

El cual podemos obtener con el siguiente código.

using (ContextCliente ct = new ContextCliente())

{                

    var model = EdmMetadata.TryGetModelHash(ct);             

}

A simple vista vemos que hay una diferencia y es por eso el motivo de recibir “InvalidOpertationException”.

Lógicamente se pueden definir estrategias que para mi son peores que recibir la exception.

1. Eliminar la bb.dd cada vez que se hace un cambio, con algo como lo siguiente.

   1: System.Data.Entity.Database.SetInitializer(new DropCreateDatabaseIfModelChanges<ContextCliente>());

2. Eliminar de las conventions “IncludeMetadataConvention” que aún es peor solución puesto que tarde o temprano cantará:).

Como se puede observar en versión 4.2 bastantes cosas desde mi punto de vista mal pensadas, pero bueno eso es parte del pasado y lo mejor como siempre es ser positivos:)

Ahora vamos a demostrar como ese Hash se genera a partir de un Xml y de esa forma eliminar parte del mito “CodeFisrt no utiliza Xml”. Señores síiii:)

Vamos a dejar nuestro ContextCliente de la siguiente forma y utilizar un montón de Reflection para ver lo que se convierte a Hash.

public class ContextCliente : DbContext

{        

    protected override void OnModelCreating(DbModelBuilder modelBuilder)

    {

       

        //Agregamos ClienteEntityConfigurtarion 

        // a modelBuilder.Configuration

        modelBuilder.Configurations.Add(new ClienteEntityConfiguration());

        

        //Obtenemos un DbModel

        var Model = modelBuilder.Build(this.Database.Connection);

    

        //Obtenemos una clase internal

        //Llamada "DbDatabaseMetadataExtensions"

        Type t = (from b in typeof(DbContext).Assembly.GetTypes()

                 where b.Name == "DbDatabaseMetadataExtensions"

                 select b).FirstOrDefault();

    

        //De esa clase el Metodo ToStoreItemCollection

        var Method = (from b in t.GetMethods(BindingFlags.Static | BindingFlags.Public)

                      where b.Name == "ToStoreItemCollection"

                      select b).FirstOrDefault();

    

        //Obtenemos del DbModel la propiedad "DatabaseMapping"

        var DataBaseMappingProperty = Model.GetType().GetProperty("DatabaseMapping", BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);

    

        var DataBaseMapping = DataBaseMappingProperty.GetValue(Model, null);

        //Obtenemos de DataBaseMapping la propiedad Database

        var DataBaseMetadaProperty = DataBaseMapping.GetType().GetProperty("Database",BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);

    

        var DataBase = DataBaseMetadaProperty.GetValue(DataBaseMapping, null);

    

        Action<string> Action = (xml) =>

            {

                Console.WriteLine(ComputeSha256Hash(xml));                    

            };

        //Invocamos al metodoToStoreItemCollection

        Method.Invoke(DataBase, new object[] { DataBase, Action });

        Console.ReadLine();          

    

    }

    

    static string ComputeSha256Hash(string input)

    {

        byte[] buffer = GetSha256HashAlgorithm().ComputeHash(Encoding.ASCII.GetBytes(input));

        StringBuilder builder = new StringBuilder(buffer.Length * 2);

        foreach (byte num in buffer)

        {

            builder.Append(num.ToString("X2", CultureInfo.InvariantCulture));

        }

        return builder.ToString();

    }

    

    

    

    static SHA256 GetSha256HashAlgorithm()

    {

        try

        {

            return new SHA256CryptoServiceProvider();

        }

        catch (PlatformNotSupportedException)

        {

            return new SHA256Managed();

        }

    }

}

Solo os invito a que pongáis un breakPoint dentro del Action<string>

Y veáis el valor del parametro “xml”. Bueno para los más gandulones os lo muestro yo:)

<?xml version="1.0" encoding="utf-16"?>

<Schema Namespace="CodeFirstDatabaseSchema" Provider="System.Data.SqlClient" ProviderManifestToken="2008" Alias="Self" xmlns="http://schemas.microsoft.com/ado/2009/02/edm/ssdl">

  <EntityType Name="Cliente">

    <Key>

      <PropertyRef Name="Id" />

    </Key>

    <Property Name="Id" Type="int" StoreGeneratedPattern="Identity" Nullable="false" />

    <Property Name="Nombre" Type="nvarchar" MaxLength="100" Nullable="false" />

  </EntityType>

  <EntityType Name="EdmMetadata">

    <Key>

      <PropertyRef Name="Id" />

    </Key>

    <Property Name="Id" Type="int" StoreGeneratedPattern="Identity" Nullable="false" />

    <Property Name="ModelHash" Type="nvarchar(max)" Nullable="true" />

  </EntityType>

  <EntityContainer Name="CodeFirstDatabase">

    <EntitySet Name="Cliente" EntityType="Self.Cliente" Schema="dbo" Table="Clientes" />

    <EntitySet Name="EdmMetadata" EntityType="Self.EdmMetadata" Schema="dbo" Table="EdmMetadata" />

  </EntityContainer>

</Schema>

Convencidos que el Hash de la versión 4.2 de CodeFirst se genera a partir del xml del Modelo:).

Bueno publico y voy con el segundo en CodeFirst 4.3 no es Hash sino un edmx comprimido.

El respositorio genérico.Un Derrochador en épocas de crisis.

2012-06-07T09:56:00Z

Durante muchos días,semanas,meses e incluso años he visto la siguiente definición de un repositorio.

1. Interface IRepository.

public interface IRepository<T> where T:class

{

   T Get(int Id);

   T Insert(T Entity);

   void Update(T Entity);

   void Delete(T Entity);

   IEnumerable<T> GetAll();

  

   IUnitOfWork UnifOfWork { get;}

}

2. Interface IUnitOfWork

public interface IUnitOfWork

{

    void Commit();

    void RollBack();

}

3. Interface IContext que implementamos en nuestro contexto de Entity Framework, en ella simplemente voy a definir un método que me devuelva un DbSet<T>

public interface IContext:IUnitOfWork

{

    DbSet<TEntity> CreateSet<TEntity>() where TEntity : class;

}

El objetivo de este post no es demostrar que evidentemente estamos ligados fuertemente a EF, desde el momento que utilizamos DbSet<T>, sino analizar la interface IRepository.

Para ello voy a crear una clase base o Layer Supertype donde voy a implementar la interface IRepository

public class Repository<T> : IRepository<T> where T:class

{

    readonly IContext _Context;

    readonly IUnitOfWork _UnitOfWork;

    public Repository(IContext Context)

    {

        if (Context == null)

            throw new NullReferenceException("El contexto no puede ser nulo");

  

        _Context = Context;

        _UnitOfWork = Context;

    }

    public T Get(int Id)

    {

        return GetSet().Find(Id);

    }

  

    public T Insert(T Entity)

    {

        throw new NotImplementedException();

    }

  

    public void Update(T Entity)

    {

        throw new NotImplementedException();

    }

  

    public void Delete(T Entity)

    {

        throw new NotImplementedException();

    }

  

    public IEnumerable<T> GetAll()

    {

        return GetSet().AsEnumerable();

    }

  

    public IUnitOfWork UnifOfWork

    {

        get { return _UnitOfWork; }

    }

    private DbSet<T> GetSet()

    {

        return _Context.CreateSet<T>();

    }

}

Como podéis observar los métodos Insert,Update y Delete no están implementados, puesto que como dije anteriormente no es objetivo de este post y aparte tampoco me apetece:).

Vamos a realizar un análisis de esto.

1. Estamos ligados a EF sí y no más comentarios:).

2.La interface IRepository<T> expone métodos que con total seguridad no necesitemos? Sí.

Un ejemplo sencillo la entidad X no se puede modificar ni eliminar. Para ello os recomiendo esta lectura que ayer concretamente twitee.

https://twitter.com/_PedroHurtado/status/210311759872000000

3. Si vemos estas pegas y lo seguimos utilizando, porque no le damos una vuelta de tuerca. Para ello os voy a exponer el siguiente requisito y lógicamente no voy a escribir todas las entidades necesarias sino quiero que os lo imaginéis:).

Un Cliente tiene una forma de pago asignada por defecto, para que cuando cree una nueva factura se la asigne a esta. Con no otro objetivo que ayudar al usuario y este lógicamente podrá cambiarla por cada operación, entendido no?

Tal y como hemos creado nuestro repositorio no nos queda otra opción que leer todos los datos del cliente y no son tres campos en la vida real. Para obtener el Id y la Descripción de la forma de pago tenemos que leer todos los datos del cliente y además hacer otra lectura para recuperar el nombre de la forma de pago. Luego nos quejamos que EF es lento o somos nosotros los que lo hacemos lento.

Porque no exponemos nuestro método Get con la siguiente firma

TResult Get<TResult>(int Id,Expression<Func<T,TResult>> Select);

Lo mismo ahora podemos implementar nuestro Get de esta forma

public TResult Get<TResult>(int Id, Expression<Func<T, TResult>> Select)

{

    return GetSet()

            .Where(c => c.Id == Id)

            .Select(Select)

            .FirstOrDefault();

}

y definir un repositorio para la clase Cliente que nos devuelva bien la Entidad Cliente o parte de ella, queréis verlo?

Bueno pues escribimos las clases necesarias para ello y veréis:)

public class Entity

{

   public int Id { get; set; }

}

public class Cliente:Entity

{       

   public string Nombre { get; set; }

   public FormaPago FormaPago { get; set; }

}

public class FormaPago:Entity

{

   public string Nombre { get; set; }

}

public interface IRepositoryCliente : IRepository<Cliente>

{

  

}

public class RepositoryCliente : Repository<Cliente>, IRepositoryCliente

{

   public RepositoryCliente(IContext Context)

       : base(Context)

   {

   }

}

  

public class Contexto : DbContext, IContext

{

  

   public DbSet<TEntity> CreateSet<TEntity>() where TEntity : class

   {

       throw new NotImplementedException();

   }

  

   public void Commit()

   {

       throw new NotImplementedException();

   }

  

   public void RollBack()

   {

       throw new NotImplementedException();

   }

}

Mirad lo que puedo hacer, ooooo!!!

public class Test

{

    public Test()

    {

        using (Contexto ct = new Contexto())

        {

            var idCliente =10;

            var repositorio = new RepositoryCliente(ct);

            //Devolver un cliente

            var cliente = repositorio.Get(idCliente, c => c);

            //Devolver partes de un cliente

            var formapago = repositorio.Get(idCliente, c => new { Id = c.FormaPago.Id, Nombre = c.FormaPago.Nombre });

            

        }

    }

}

Pero lo que más me gusta es esto.

Pedro la verdad que eres un sacrílego, no se cuantos principios has roto y cuantos antipatrones has implementado, además un método que devuelve un Tipo Anónimo.

Yo me contesto. Si lo que tu me digas, pero yo necesito el Id y el Nombre de la Forma de Pago no doscientos campos que tiene el Cliente. Anda derrochador,malgastoso no vas a tener ni un duro cuando seas mayor:).

Conclusiones.

Porque no nos acostumbramos a leer exclusivamente lo que necesitamos y nos dejamos de películas, creo que la vida nos irá mejor. Una última reflexión, ¿me habré cargado AutoMapper?. Otro malgastoso, o estoy en el camino:).

Var (II).Los hermanos de Simba

2012-05-17T10:41:00Z

Este post viene como consecuencia de los comentarios del gran @eiximenis, en este otro var en c# si, o var no. Lo que ha hecho Eduard es elevar con la segunda respuesta la entrada al destino de los elegidos:).

Referente al titulo “Los hermanos de Simba” es porque la fiera se va a comer al gatito.

La primera de las respuestas, he de reconocer que estuve pensando en escribirla en el primero de los post, pero eso de la vida que te hace perezoso y en un momento decides cortar.

Eduard nos dice lo siguiente.

Efectivamente, como bien dices en var el tipo del lvalue es siempre igual al del rvalue (eso es var precisamente). Pero, en según que ocasiones, eso no nos sirve... Un ejemplo rápido...

myListbox.Items.Add(new Foo());

foreach (var fooItem in myListbox.Items) { ... }

En este caso, al usar var, fooItem es un Object, pero si yo sé que en la lista hay solo Foo, probablemente querré que fooItem sea de tipo Foo. Este es solo un ejemplo. A eso me refería yo ;-)

Por que ocurre esto? Porque en el ejemplo Eduard está utilizando un ObjectCollection, claro a alguien le pareció demasiado tedioso con la aparición de generic reescribir Windows Form y demás y lo que se hizo fue dejar la cosa como estaba e implementar IEnumerable<T>, todos sabemos que para utilizar el magnifico foreach alguien debe de implementar en sus clases como mínimo IEnumerable y digo como mínimo, puesto que lo lógico es utilizar IEnumerable<T>.

Vamos con un ejemplo, partimos de la siguiente clase.

public class Foo

{  

   

}

Si yo escribo el siguiente conjunto de instrucciones

var foo = new Foo();

foreach (var item in foo)

{

  

}

Recibo un error de compilación donde me dice lo siguiente.

La instrucción foreach no puede funcionar en variables de tipo 'Namespace.Foo' porque 'Namespace.Foo' no contiene ninguna definición pública para 'GetEnumerator'.

Sí Implementamos IEnumerable en “Foo”.

public class Foo:System.Collections.IEnumerable

{

  

    public System.Collections.IEnumerator GetEnumerator()

    {

        throw new NotImplementedException();

    }

}

A partir de este momento yo puedo ejecutar foreach in “Foo”.

Pero claro, con esto no contestamos a Eduard, para ello nos debemos fijar en el valor devuelto por GetEnumerator un IEnumerator cuya definición es la siguiente.

[ComVisible(true), Guid("496B0ABF-CDEE-11d3-88E8-00902754C43A")]

public interface IEnumerator

{

    bool MoveNext();

    object Current { get; }

    void Reset();

}



Si nos fijamos Current es object, por eso es por lo que a “var” se le asigna un “object”, con lo cual “var” si está haciendo lo que dice hacer.

Claro porque “var” si funciona con List<T>,etc,etc, pues sencillo porque estos han subido un nivel y han implementado IEnumerable<T> y por tanto IEnumerator<T> donde la propiedad Current devuelve T.

public interface IEnumerator<T> : IDisposable, IEnumerator

{

    // Properties

    T Current { get; }

}

Pero como se que me va a decir que porque yo puede hacer lo siguiente.

private void Metodo()

{

    var Lista = new System.Collections.ArrayList();

    Lista.Add(new Foo());

    foreach (Foo item in Lista)

    {

  

    }

}

Le vamos a contestar, con un simple “una cosa es lo que tus ojos ven y otra bien distinta lo que hay”.

Un poquito de IL:).

.method private hidebysig instance void Metodo() cil managed

{

    .maxstack 2

    .locals init (

        [0] class [mscorlib]System.Collections.ArrayList Lista,

        [1] class WindowsFormsApplication24.Foo item,

        [2] class [mscorlib]System.Collections.IEnumerator CS$5$0000,

        [3] bool CS$4$0001,

        [4] class [mscorlib]System.IDisposable CS$0$0002)

    L_0000: nop 

    L_0001: newobj instance void [mscorlib]System.Collections.ArrayList::.ctor()

    L_0006: stloc.0 

    L_0007: ldloc.0 

    L_0008: newobj instance void WindowsFormsApplication24.Foo::.ctor()

    L_000d: callvirt instance int32 [mscorlib]System.Collections.ArrayList::Add(object)

    L_0012: pop 

    L_0013: nop 

    L_0014: ldloc.0 

    L_0015: callvirt instance class [mscorlib]System.Collections.IEnumerator [mscorlib]System.Collections.ArrayList::GetEnumerator()

    L_001a: stloc.2 

    L_001b: br.s L_002b

    L_001d: ldloc.2 

    L_001e: callvirt instance object [mscorlib]System.Collections.IEnumerator::get_Current()

    L_0023: castclass WindowsFormsApplication24.Foo

    L_0028: stloc.1 

    L_0029: nop 

    L_002a: nop 

    L_002b: ldloc.2 

    L_002c: callvirt instance bool [mscorlib]System.Collections.IEnumerator::MoveNext()

    L_0031: stloc.3 

    L_0032: ldloc.3 

    L_0033: brtrue.s L_001d

    L_0035: leave.s L_0051

    L_0037: ldloc.2 

    L_0038: isinst [mscorlib]System.IDisposable

    L_003d: stloc.s CS$0$0002

    L_003f: ldloc.s CS$0$0002

    L_0041: ldnull 

    L_0042: ceq 

    L_0044: stloc.3 

    L_0045: ldloc.3 

    L_0046: brtrue.s L_0050

    L_0048: ldloc.s CS$0$0002

    L_004a: callvirt instance void [mscorlib]System.IDisposable::Dispose()

    L_004f: nop 

    L_0050: endfinally 

    L_0051: nop 

    L_0052: ret 

    .try L_001b to L_0037 finally handler L_0037 to L_0051

}

y más concretamente nos vamos a centrar en estás dos instrucciones

L_001e: callvirt instance object [mscorlib]System.Collections.IEnumerator::get_Current()

L_0023: castclass WindowsFormsApplication24.Foo

Hombre un OpCodes.Castclass. Lo más bonito de este link no es otra cosa que la siguiente frase.

“Intenta convertir un objeto pasado por referencia en la clase especificada”

Efectivamente “intenta”, con lo cual si no puede, sorpresa y nos llevaremos como premio, un magnifico “InvalidCastException” y para ello simplemente creamos una clase Foo1 y la agregamos al ArrayList.

private void Metodo()

{

 var Lista = new System.Collections.ArrayList();

 Lista.Add(new Foo());

 Lista.Add(new Foo1());

 foreach (Foo item in Lista)

 {

  

 }

}

Lo que es evidente, que var funciona, puesto que es imposible saber que es lo que ArrayList tiene. Solo sabemos que tiene object y por tanto “var” es “object”.

Pero se te olvido una cosa OfType<T>() y entonces “var” si que funciona perfectamente, aunque que quede claro que no aconsejo el uso de esta instrucción en este caso, puesto que nos comemos un elemento. Lo que si aconsejo es que nos olvidemos para siempre si puede ser de las colecciones no genericas, aunque algunas veces es imposible y más cuando se trata de collecction ligadas a WindowsForm,WPF,Silverlight, que bastante mal se llevan con el uso de Generic.

En definitiva para que “var” funcione correctamente en este caso basta con escribir lo siguiente.

private void Metodo()

{

    var Lista = new System.Collections.ArrayList();

    Lista.Add(new Foo());

    Lista.Add(new Foo1());

    foreach (var item in Lista.OfType<Foo>())

    {

  

    }

}

Aunque como dije anteriormente el segundo elemento nos lo comemos, de esta forma veo que yo si utilizaría “var” siempre en un foreach.

Cuando me refería a no abusar, me refería, aunque se puede, a utilizar este tipo de cosas.

   1: var i = ((Func<int, int, int>)((x, y) => x + y))(10,10);

Esto me recuerda a un antiguo compañero que cuando sumaba enteros escribía “var z = 0x3e8 + 0x3e8;” que si hombre que sí que z = 2000 ó z = 1000+ 1000;

Aclarado el primer comentario, vamos con el segundo que ese si que está lleno de mala leche:).

La pregunta es... Suponiendo que lo anterior compilase, esa otra línea debería hacerlo?

var r = (x1,x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x12,x13,x14,x15,x16,x17 => x1+x17)(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17);

Repito: si la sentencia anterior compilase, esa debería compilar también? Sí? No? Tic, tac...

PD: Si, admito que si alguien crea una lambda con 17 parámetros es para darle una colleja :P

La respuesta es No y os explico, para ello nos debemos trasladar a la primera aparición de Func y Action en el Framework 3.5. El número maximo de parametros permitidos eran 4.

Si avanzamos en el tiempo y analizamos esto mismo a partir del Framework 4.0 nos encontramos con que los parametros permitidos son 16, fijaos en la maldad de poner 17:).

tic,tac…. Pero no conformándonos con esto vamos a demostrarle a Eduard que si compilo.

Alguien me impide a mí definir un Func y un Action con 17 parámetros o con 50, pues no otra cosa es que directamente te pueden llamar “ñapas”:).

namespace System

{

    public delegate TResult Func<in T1, in T2, in T3, in T4, in T5, in T6, in T7, in T8, in T9, in T10, in T11, in T12, in T13, in T14, in T15, in T16,in T17, out TResult>(T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10, T11 arg11, T12 arg12, T13 arg13, T14 arg14, T15 arg15, T16 arg16,T17 arg17); 

  

}

Y ahora vamos a hacer que compile utilizando “var”.

var i = ((Func<int, int, int,int,int,int,int,int,int,int,int,int,int,int,int,int,int,int>)

               ((x1, x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x12,x13,x14,x15,x16,x17) => 

                 x1+x2+x1+x4+x5+x6+x7+x8+x9+x10+x11+x12+x13+x14+x15+x16+x17))

               (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17);

Console.Write(i);

El resultado obtenido que es pues sencillo 151, pero claro no debéis de utilizar esta técnica para sumar una secuencia de números correlativa, mas vale que veáis este video.

http://www.youtube.com/watch?feature=player_embedded&list=PLB33C2EAFBCB22655&v=9gv2YyRvdB0

Tic,Tac……

Saludos,

var en c# si, o var no

2012-05-16T15:55:00Z

Este es de esos post donde uno piensa exactamente igual que cuando deshoja una margarita. Me quiere no me quiere. Mi opinión antes de seguir es que la quiero:).

Todo esto surge a raíz de una conversación en twitter que podéis seguir aquí y que lógicamente expuso diferentes opiniones que al final es en lo que consiste, Yo opino, tu opinas.

¿Quien tiene la razón? todos:).

Un poco de puesta en escena

https://twitter.com/#!/_PedroHurtado/status/202057547094564864, claro yo haciendo caso omiso a los consejos de mi padre “Pedro Dios te dio dos orejas para escuchar el doble de lo que hablas”. No se me ocurre otra cosa que lanzar esto:).

https://twitter.com/#!/_PedroHurtado/status/202058984570621953 y después no conforme con esto un poco más de fuerza bruta.

https://twitter.com/#!/_PedroHurtado/status/202060219935756288

Con lo cual surge todo esto.

https://twitter.com/#!/_PedroHurtado/status/202061813746110464 y más. Que no es necesario hacerse pesado y vamos al grano.

Que es var?

De las pocas cosas que da gusto leer en el MSND y uno se entera. Es la definición de Variables locales con asignación implícita de tipos (Guía de programación de C#).

Pero si nos centramos en esto vemos cosas que deberían tener algún que otro comentario.

“A las variables locales se les puede asignar un "tipo" deducido var en lugar de un tipo explícito. La palabra clave var indica al compilador que deduzca el tipo de la variable a partir de la expresión que se encuentra en el lado derecho de la instrucción de inicialización”

Efectivamente Eduard(@eiximenis), discrepo totalmente en tu afirmación “cuando el tipo del lvalue es distinto al tipo del rvalue... ;)” no creo que lvalue entendido como la parte izquierda sea distinto jamás al rvalue es decir el lvalue es deducido o mejor dicho inferido a partir del rvalue, con lo cual todo es valido para “var” y lo vamos a ver:).

@Jonathan_JFR, te voy a explicar porque los tipos anónimos o lambda expresion no se pueden inferir, para ello te recomiendo esta lectura Why can't an anonymous method be assigned to var?. En la cual el gran Eric Lippert metió la pata hasta donde se puede meter:), me quedo con la respuesta de Mehrdad.

“@Eric: Good answer, but it's slightly misleading to illustrate this as something that's not possible, as this actually works completely fine in D. It's just that you guys didn't choose to give delegate literals their own type, and instead made them depend on their contexts... so IMHO the answer should be "because that's how we made it" more than anything else. :)”

Pues si Eriq es confuso y te voy a poner un ejemplo sencillo.

var i = 123;

Esto que es?

Un int,uint,short,ushort,long,ulong,sbyte,byte

¿Por qué se infiere un int?

Creo que “porque así se decidió”.

Con lo cual tu para inferir un "tipo integrado” o un ValueType te tienes que ir a la siguiente tabla.

Tabla de valores predeterminados (Referencia de C#).

En resumen si yo quiero hacer que i sea del tipo Decimal tengo que hacer esto.

var i=123M; o bien var i = 123m; es decir hacer uso de los Literales y más concretamente de los sufijos de estos o bien en el caso de short que no lo tiene hacer uso de lo siguiente.

var i=(short)0;

A partir de este momento es fácil deducir como una Lambda Expresion o bien un Método Anónimo lo puedo poner a la derecha de “var”.

var i = delegate(int y) //Error No se puede asignar metodo anonimo a una variable local tipificada implicitamente

{

   return y * 2;

};

var i = ((Func<int,int>)delegate(int y) //Ok

{

   return y * 2;

});

Ahora vamos con las Lambda Expresion, estás pueden devolver o un Func,etc,etc o bien o una Expresión es decir esto sería un Func.

   1: Func<int, int, int> b = (x,y)=>x*y;

o eso mismo podría ser

   1: Expression<Func<int, int, int>> b = (x, y) => x * y;

Alguien me impide a mi hacer esto.

   1: var i = (int x, int y) => x * y;

Si el compilador, pero que ocurre si hago lo siguiente, pues que todo funciona.

var i = (Func<int,int,int>)((x,y)=>x+y);

var resultado = i(10, 10);

Console.WriteLine(i.GetType());

Console.WriteLine(resultado.GetType());

Console.WriteLine(resultado);

Os imagináis el resultado, pues os lo muestro.

System.Func`3[System.Int32,System.Int32,System.Int32]
System.Int32
20

Otra cosa, puede hacer esto?.

var i = null, pues no y para ello lo mejor que podemos es revisar lo siguiente. Implicitly Typed Local Variables, concretamente el apartado de “restrictions”.

Pues sí puedo hacer y muchas cosas más.

var nullint32 =(int?)0;

var nulo = (Clase)null;

var xByte = (byte)0;

var Xdecimal= 0M;

var XLong = 0L;

var XDouble = 0D;

var XUint = 0U;

var XShort = 0;

var xFloat = 0F;

var XChar = '1';

var XEnum = (aaa)1;

var xShort = (short)32767;

Y de esta forma todas las que se os ocurran:).

Conclusiones.

1. Que como todo tiene su razón de ser, que se puede utilizar y ahorrar trabajo es evidente.

2. Que si abusamos puede llegar a ser malo, también.

3. Yo lo utilizo siempre en linq, tipos anonimos,al crear un nuevo objeto, en using,devoluciones de metodos y foreach y hasta el momento no he tenido ningún problema.

4. Es el Dim de Vb. Nooooooooooooooo.

5. Es un variant de vb o bien un object de c#. Nooooooooo, si revisamos el IL vemos que exactamente tanto una como la otra sentencia genera lo mismo.

int i = 10;

var i=10;

6. Es confuso Noooooooooo, para mi confuso es no poner nombres claros a las variables, eso si que es confuso.

El scroll infinito.

2012-05-08T19:54:00Z

Hola, os acordáis de Pepe, si hombre el usuario que nos ayudo a crear el patrón “Engañabobos”. Seguro que a alguno y es normal le puede sonar a risa, por eso lo lógico, es que leáis antes este post .

Después de pensar que todo estaba solucionado, suena el teléfono y como no, es otra vez “Pepe”. Su frasecita “esto sigue igual de lento”.

Nos ponemos a trabajar,pensamos en voz alta y decimos :

1. Si estamos paginando.

2. Hemos hecho un análisis de las consultas y todas van bien.

Que puede pasar? Minutos después nos dimos cuenta que si que estábamos haciendo todo eso , pero….

Se ejecutaba un “SELECT COUNT()” en cada Round-Trip, para mostrar el número de paginas al usuario.

Efectivamente hemos localizado el problema, pero como lo solucionamos, pues sencillo y por eso el título.

Alguien utiliza twitter, a que sí, pues vamos a hacerlo para MVC.

1. Definimos una clase sencilla llamada Datos. Hoy no tenemos entidades ni EF, ni nada de eso.

        1: using System;

       2: using System.Collections.Generic;

       3: using System.Linq;

       4: using System.Web;

       5:  

       6: namespace MvcApplication17.Models

       7: {

       8:     public class Datos

       9:     {

      10:         public int Id { get; set; }

      11:         public string Nombre { get; set; }

      12:     }

      13: }

2. En nuestro controlador vamos a escribir lo siguiente en el método Index.

       1: public ActionResult Index(int? Pagina)

       2: {

       3:     ViewBag.Message = "Welcome to ASP.NET MVC!";

       4:  

       5:     List<Datos> datos = new List<Datos>();

       6:  

       7:     for (int i = 0; i < 500; i++)

       8:     {

       9:         int id = i+1;

      10:         datos.Add(new Datos() { Id = id, Nombre = string.Format("Nombre {0}", id) });

      11:     }

      12:  

      13:     var Skip = Pagina ?? 0;

      14:     var Take = 50;

      15:     var model = datos.Skip(Skip * Take).Take(Take);

      16:  

      17:     if (!Request.IsAjaxRequest())

      18:     {

      19:         return View(model);

      20:     }

      21:     else

      22:     {

      23:         return Json(model, JsonRequestBehavior.AllowGet);                                     

      24:     }

      25: }

Fijaos en un detalle “Request.IsAjaxRequest()”, con esto lo que hago es controlar si me están haciendo peticiones vía Ajax.

3. Nos queda la vista y un poco de algunas cosas. Siguiendo este magnífico post de @jmaguilar y viendo que podemos utilizar MVVM,uno de mis favoritos, nos ponemos manos a la obra:).

Para ello voy a utilizar dos referencias que podéis encontrar en la pagina oficial de knockout.

The "template" binding

The "attr" binding

Es decir nuestra vista va a quedar de la siguiente forma.

       1: @using MvcApplication17

       2: @model IEnumerable<MvcApplication17.Models.Datos>

       3:            

       4: @{

       5:     ViewBag.Title = "Home Page";    

       6: }

       7: <script src="@Url.Content("~/Scripts/knockout.js")" type="text/javascript"></script>   1:     2: <h2>@ViewBag.Message</h2>   3:     4: <p>   5:     @Html.ActionLink("Create New", "Create")   6: </p>   7:     8: @*Tabla*@   9: <table data-bind="template: { name: 'data-template', foreach: items }">  10: <thead>  11:     <tr>          12:         <th>Nombre</th>  13:         <th></th>  14:     </tr>  15: </thead>  16: </table>   17:    18: @*Template*@  19: <script type="text/html" id="data-template">  20:     <tr>      21:     <td data-bind="text: Nombre"></td>      22:     <td>  23:         <a data-bind="attr: { href: 'Home/Edit/' + Id}">Edit</a>|  24:         <a data-bind="attr: { href: 'Home/Details/' + Id}">Details</a>|  25:         <a data-bind="attr: { href: 'Home/Delete/' + Id}">Delete</a>  26:      </td>  27:     </tr></script>

Claro esto no hace absolutamente nada, para ello, tenemos que utilizar javascript y dar vida a esta paginación.

       1: <script type="text/javascript">

       2: var Home_Index = {

       3:     items:ko.observableArray(@Html.Raw(@Json.Encode(Model))),

       4:     pagina:0,

       5:     endData:false,

       6:     redord:50,

       7:     scroll:function(){

       8:         if(($(window).scrollTop() == $(document).height() - $(window).height()) && !Home_Index.endData){

       9:             Home_Index.pagina++;

      10:             $.getJSON('Home/Index',{pagina:Home_Index.pagina},Home_Index.nextPage)

      11:         }

      12:     },

      13:     nextPage :function(data){

      14:         if (data.length>0){

      15:             $.each(data, function(i, item){

      16:                 Home_Index.items.push(item);

      17:             });

      18:         }      

      19:  

      20:         if (data.length < Home_Index.record){

      21:            Home_Index.endData=true;

      22:             Home_Index.paginga--;

      23:      

      24:         }

      25:     }              

      26: };

      27: ko.applyBindings(Home_Index);

      28: $(window).scroll(Home_Index.scroll);

      29: </script>

Y de repente nos encontramos con que “Pepe” está contento podemos paginar sin hacer un Count().

En definitiva nos tenemos que centrar en lo siguiente.

items:ko.observableArray(@Html.Raw(@Json.Encode(Model))),

Con esto evitamos que en la primera llamada tengamos que hacer una nueva llamada via ajax, cosa que he visto en muchas ocasiones. Cargar la pagina y después uno de los plugin hace una llamada para refrescar los datos.

El resto poca explicación tiene para los más puestos en javascript excepto esta línea de la que podéis ampliar información Observables .

ko.applyBindings(Home_Index);

Claro alguno dirá, pero estar compiando esto en cada vista, como que no, pues os voy a dar una idea, podéis utilizar un método extensor y extender el objeto HmtlHelper, os paso la firma del método y quien quiera que se ponga manos a la obra:)

       1: public static class MisHelper

       2: {

       3:     public static MvcHtmlString InfiniteScroll(this System.Web.Mvc.HtmlHelper Helper,string Controller, string Action,int Record,object Model)

       4:     {

       5:         string Type = string.Format("{0}_{1}",Controller,Action);

       6:         StringBuilder sb = new StringBuilder();          

       7:         

       8:         //El resto es trabajo vuestro:)

       9:          

      10:         TagBuilder script = new TagBuilder("script");

      11:         script.Attributes.Add("Type", "text/javascript");

      12:         script.InnerHtml = sb.ToString();

      13:  

      14:       

      15:  

      16:         return new MvcHtmlString(script.ToString(TagRenderMode.Normal));

      17:     }

      18: }

Si hacemos esto conseguiremos en nuestra vista no tener esa cantidad de javascript y ejecutar esto vía razor.

@Html.InfiniteScroll("Home", "Index", 50, Model);

Como todos no son virtudes y existe algún que otro problema y sobre todo con Javascript y el formateo de fechas y números que lo odio:). Os voy a contar otra forma que se me ha ocurrido.

Separar mi vista en dos y las filas de la tabla generarlas en una vista parcial.

1. Controlador.

       1: public ActionResult Index(int? Pagina)

       2: {

       3:    ViewBag.Message = "Welcome to ASP.NET MVC!";

       4:  

       5:    List<Datos> datos = new List<Datos>();

       6:  

       7:    for (int i = 0; i < 500; i++)

       8:    {

       9:        int id = i+1;

      10:        datos.Add(new Datos() { Id = id, Nombre = string.Format("Nombre {0}", id) });

      11:    }

      12:  

      13:    var Skip = Pagina ?? 0;

      14:    var Take = 50;

      15:    var model = datos.Skip(Skip * Take).Take(Take);

      16:  

      17:    if (!Request.IsAjaxRequest())

      18:    {

      19:        return View(model);

      20:    }

      21:    else

      22:    {

      23:        return PartialView("_TableIndex", model);

      24:        //return Json(model, JsonRequestBehavior.AllowGet);                                     

      25:    }

      26: }

Si os fijáis la diferencia es sencilla en vez de devolver Json lo que hago es devolver un PartialViewResult.

2. Nuestra vista quedaría de la siguiente forma.

       1: @using MvcApplication17

       2: @model IEnumerable<MvcApplication17.Models.Datos>

       3:            

       4: @{

       5:     ViewBag.Title = "Home Page";    

       6: }

       7:  

       8: <h2>@ViewBag.Message</h2>

       9:  

      10: <p>

      11:     @Html.ActionLink("Create New", "Create")

      12: </p>

      13:  

      14: <table id = "Grid">

      15:     <tr>

      16:         <th>

      17:             Nombre

      18:         </th>

      19:         <th></th>

      20:     </tr>

      21:     @Html.Partial("_TableIndex",Model)

      22: </table>

      23: <script type="text/javascript">   1:     2:     var Home_Index = {   3:         pagina: 0,   4:         endData: false,   5:         redord: 50,   6:         scroll: function () {   7:             if (($(window).scrollTop() == $(document).height() - $(window).height()) && !Home_Index.endData) {   8:                 Home_Index.pagina++;                   9:                 $.get('Home/Index', { pagina: Home_Index.pagina }, Home_Index.nextPage);  10:             }  11:         },  12:         nextPage: function (data) {             13:             data = data.replace(/^\s*|\s*$/g, "");  14:             alert($(data).size())  15:             if ($(data).length > 0) {  16:             $('#Grid tr:last').after(data);  17:             }  18:             else {  19:             Home_Index.pagina--;  20:             Home_Index.endData = true;  21:             }  22:         }  23:     };  24: $(window).scroll(Home_Index.scroll);</script>

3. Nuestra vista parcial.

       1: @model IEnumerable<MvcApplication17.Models.Datos>

       2: @foreach (var item in Model) {

       3:     <tr>

       4:         <td>

       5:             @Html.DisplayFor(modelItem => item.Nombre)

       6:         </td>

       7:         <td>

       8:             @Html.ActionLink("Edit", "Edit", new { id=item.Id }) |

       9:             @Html.ActionLink("Details", "Details", new { id=item.Id }) |

      10:             @Html.ActionLink("Delete", "Delete", new { id=item.Id })

      11:         </td>

      12:     </tr>

      13: }

Analicemos pues las ventajas y desventajas de utilizar esta última, tenemos más control como se puede ver gracias a Razor y el trabajo en el servidor, por contra al devolver html la diferencia en bytes entre utilizar la primera y la segunda forma es notable 12 Kb frente a 1.5 Kb devolviendo Json en cada petición, es decir bastante diferencia.

Conclusiones.

Poco tiene esto que decir, mas que educar a nuestros usuarios para adaptarse a nuevas formas de ver la información y que pequeños detalles como este, hacen que una aplicación corra o se arrastre:).

Con esto cerramos los proxis dinámicos de EF

2012-05-03T23:26:00Z

En mi anterior post y con bastante ánimo de critica intente explicar mi desacuerdo con ciertas cosas que pasan sin nuestro control. En este lo que intento es que todos conozcáis que es lo que pasa con algunas recomendaciones “Si trabajas con EF declara tus propiedades como virtual que es mejor” .

Mejor ¿Por qué?. Vamos a verlo:).

Si pensamos detenidamente cuando yo declaro algo con el modificador de acceso virtual es porque lo dejo preparado para que otra persona sea capaz de reemplazarlo con override. Es así no?.

Para poneros un poco en antecedentes os recomiendo estos dos post que os pueden ayudar a aclarar ciertas dudas.

Seguro que más de uno lo ha leído, pues Codefirst funciona igual y sino de donde la magia.

Pero me quedo con esta frase “Proxies are a form of dependency injection where additional functionality is injected into the entity”. Para mi no es Inyección de dependencias yo creo que mas que eso es una invasión:).

Otra cosa que me dio bastantes pistas fue esto

“The EF generates proxy types on the fly using the AssemblyBuilder and TypeBuilder in the .NET framework. All the code to perform lazy loading and change tracking is added to the dynamically generated types using the Reflection.Emit APIs”

Mi gran amigo Reflection.Emit desconocido pero potente para invadir. Bueno llegados a este punto, es darle un poco a la imaginación y a las malas artes para descubrir quien hace todo eso. Tras dar vueltas al código fuente con Reflector me encuentro con una clase internal. Como no!!!. Señores public y si puede ser OpenSource que esto hará que EF crezca.

Sabéis el nombre pues os lo digo

Clase :“EntityProxyFactory”

Namespace:“System.Data.Objects.Internal”

Dll: “System.Data.Entity.dll”.

Si esa que esta instalada en la GAC y que por mucho que con Nuget actualicemos la versión de EF nunca cambia.

Os acordáis de mi anterior post ese modelo malicioso de Facturas y Clientes, bueno ahora voy a hacer con el otra cosa y es ver que genera EF por nosotros.

Para ello voy a utilizar reflection y acceder a ciertos campos privados de esa clase y modificarlos para poder guardar en disco la dll generada.

BindingFlags Flags = BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic;

using (ModelFacturas db = new ModelFacturas())

{

   //Obtenemos el ensamblado System.Data.Entity.Dll

   Assembly a = typeof(System.Data.Objects.ObjectContext).Assembly;

   

   //Obtenemos el tipo EntityProxiFactory

   var type = (from item in a.GetTypes()

               where item.Name == "EntityProxyFactory"

               select item).FirstOrDefault();

  

   //Modificamos el campo privado s_ProxyAssemblyBuilderAccess para

   //permitir que el ensamblado dinamico se pueda guardar

   //por defecto AssemblyBuilderAccess está marcado como Run

   //Es decir se puede ejecutar pero no se puede Guardar

   var field = type.GetField("s_ProxyAssemblyBuilderAccess", Flags);

   

   object o = Activator.CreateInstance(type);

   field.SetValue(o, AssemblyBuilderAccess.RunAndSave);

  

   //provocamos que EF genere el proxi dinamico

  

   var cliente = db.Clientes.AsEnumerable().FirstOrDefault();

   var facturas = db.Facturas.AsEnumerable().FirstOrDefault();             

   

   //Accedemos al ensamblado dinamico y lo guardamos en disco

   var field2 = type.GetField("s_ModuleBuilders", Flags);

  

   Dictionary<Assembly, ModuleBuilder> dic = field2.GetValue(o) as Dictionary<Assembly, ModuleBuilder>;

   if (dic.Any())

   {

       AssemblyBuilder asm = dic.First().Value.Assembly as AssemblyBuilder;

       asm.Save("tequieroconocer.dll");

   }   

}

Pues a partir de este momento ya tenemos en nuestro directorio de ejecución. Una dll llamada “tequieroconocer.dll”. El siguiente paso es sencillo la abrimos con cualquier herramienta como Reflector y a disfrutar y conocer:).

Fijaos en la magia, nuestras clases originales han sido alteradas e implementan dos interfaces

El resto de cosas os las dejo para que investiguéis, vosotros y de esa forma conocer a fondo este Framework, que tiene sus cosas buenas y otras que no son tan buenas.

Conclusiones.

El conocimiento no debe de tener limites , por lo tanto tiene que ser público y es por esto el motivo de este post.

Sobre todo os tenéis que acordar de dos parámetros importantes cuando utilicéis EF.

Ya conocéis un poquito más de ellos.

Lazy Load. El bueno de Martin ya lo advirtio.

2012-04-30T22:59:00Z

Para que vayáis tomando el aperitivo de lo que viene os recomiendo primero esta lectura Lazy Load “segundo parrafo” y no esta Lazy loading. Bueno es un patrón o bien un antipatrón, para mi sencillo un antipatrón y mira que he tenido discusiones con grandes amigos al respecto, pero claro siguiendo mi línea quiero demostrar porque es un antipatrón.

Hace años y no pocos un grupo de amigos con más de una cerveza en la mano creamos un patrón para trabajar con bb.dd, aquel día no se nos ocurrió otra cosa que llamar a este “engaña bobos”. El nombre, lógicamente, vino definido por el momento.

Porque “engaña bobos”, pues sencillo el usuario nos pedía unos datos que era incapaz de ver y todos pensamos. Pues vamos a darle a sus ojos exclusivamente lo que puede ver.

10 Registro por página.
Cinco Campos.

En definitiva este señor se quejaba de la lentitud de las consultas y después de aplicar este patrón a nuestro desarrollo, el fue feliz y nosotros no te digo nada. Jo con el Pepe que no se queja:).

De verdad pensáis que estoy de broma, pues no, voy a demostrar el efecto del “engaña bobos” con Entity Framework 4.3.

Hace unos días y en una conversación de twitter me encontré con unos amigos a los que les dije lo siguiente Lazy Load el Antipatrón. Engaña bobos el patrón.

Lo demostramos, venga vamos a ello.

Primer paso. Un modelo sencillo, pero con bastante ocultismo, puesto que eso no representa ni la mitad de la vida real . Una factura y un cliente y hoy con DataAnotations, por cambiar de tercio:).

        1: public class ModelFacturas:DbContext

       2:    {

       3:        public ModelFacturas()

       4:        {

       5:            this.Configuration.LazyLoadingEnabled = false;

       6:        }

       7:        public DbSet<Cliente> Clientes { get; set; }

       8:        public DbSet<Factura> Facturas { get; set; }

       9:    }

      10: [Table("Clientes")]

      11: public class Cliente

      12: {

      13:    [Key]

      14:    public int Id { get; set; }

      15:    public string Nombre { get; set; }

      16: }

      17: [Table("Facturas")]

      18: public class Factura

      19: {

      20:    [Key]

      21:    public int Id { get; set; }        

      22:    public int ClienteId { get; set; }

      23:    [ForeignKey("ClienteId")]

      24:    public virtual Cliente Cliente { get; set; }

      25:    public Decimal Importe { get; set; }

      26:    public DateTime FechaFactura { get; set; }

      27:  

      28:  

      29: }

A que todos sabemos que oculta algo, por lo menos 50 propiedades más por entidad que cuesta leerlas:).

Segundo Paso. Pepe nos solicita una consulta con las facturas en la que tenemos que mostrar el importe, fecha de factura y nombre del cliente.

Tenemos muchas formas de hacerlo y algunas nos puede hacer que nos duela la cabeza, eso sí en desarrollo perfecto, ahora en producción Valium 10:).

1. Hemos leído muchas veces que existe un método AsNoTracking() en el objeto DbQuery que hace entre otras maravillas ganar en performace.

       1: using (ModelFacturas db = new ModelFacturas())

       2: {

       3:    var resultado = from factura in db.Facturas.AsNoTracking()

       4:                    select factura;

       5:  

       6:    foreach (var item in resultado)

       7:    {

       8:        Console.WriteLine(item.Cliente.Nombre);

       9:    }

      10: }

La verdad que sí, pero en este caso no. Recupera las facturas y por cada factura recuperada lanza la siguiente sentencia.

       1: exec sp_executesql N'SELECT 

       2: [Extent1].[Id] AS [Id], 

       3: [Extent1].[Nombre] AS [Nombre]

       4: FROM [dbo].[Clientes] AS [Extent1]

       5: WHERE [Extent1].[Id] = @EntityKeyValue1',N'@EntityKeyValue1 int',@EntityKeyValue1=1

En mi caso la simulación eran 100 registros, pues vamos a pensar en 100.000:(.

2. No me gusta, por lo tanto nos olvidamos de “AsNoTracking”

       1: using (ModelFacturas db = new ModelFacturas())

       2: {

       3:    var resultado = from factura in db.Facturas

       4:                    select factura;

       5:  

       6:    foreach (var item in resultado)

       7:    {

       8:        Console.WriteLine(item.Cliente.Nombre);

       9:    }

      10: }

Respuesta en la bb.dd, solo dos sentencias. una para recuperar las facturas y la otra para recuperar el cliente, pero una sola, menuda maravilla.

       1: SELECT 

       2: [Extent1].[Id] AS [Id], 

       3: [Extent1].[ClienteId] AS [ClienteId], 

       4: [Extent1].[Importe] AS [Importe], 

       5: [Extent1].[FechaFactura] AS [FechaFactura]

       6: FROM [dbo].[Facturas] AS [Extent1]

       7:  

       8:  

       9: exec sp_executesql N'SELECT 

      10: [Extent1].[Id] AS [Id], 

      11: [Extent1].[Nombre] AS [Nombre]

      12: FROM [dbo].[Clientes] AS [Extent1]

      13: WHERE [Extent1].[Id] = @EntityKeyValue1',N'@EntityKeyValue1 int',@EntityKeyValue1=1

Pero claro no os he contado una cosa y es que para el ejemplo hice trampas , a todas las facturas le inserte el mismo cliente:).

       1: using (ModelFacturas db = new ModelFacturas())

       2: {

       3:     Cliente cl = new Cliente() { Nombre = "Cliente1"};

       4:  

       5:  

       6:     db.Clientes.Add(cl);

       7:  

       8:     db.SaveChanges();

       9:  

      10:     for (int i = 0; i < 100; i++)

      11:     {

      12:         db.Facturas.Add(new Factura() { ClienteId = cl.Id, FechaFactura = DateTime.Now.Date, Importe = 1 });

      13:     }

      14:  

      15:     db.SaveChanges();

      16: }

Con lo cual excepto que tu empresa tenga un solo cliente y mal tiene que funcionar , el resultado es casi igual de malo.

Tercer Paso.

Vamos a aplicar el “Engaña bobos” varias formas pero una sencilla gracias a EF.

       1: using (ModelFacturas db = new ModelFacturas())

       2: {

       3:    var resultado = from factura in db.Facturas.AsNoTracking()

       4:                    select new

       5:                    {

       6:                        FacturaId = factura.Id,

       7:                        Fecha = factura.FechaFactura,

       8:                        Importe = factura.Importe,

       9:                        Cliente = factura.Cliente.Nombre

      10:                    };

      11:  

      12:    foreach (var item in resultado)

      13:    {

      14:        Console.WriteLine(item.Cliente);

      15:    }

      16:  

      17:    

      18: }

Fijaos en detalles. Aquí si utilizo “AsNoTracking”, que pasa que tengo que definir una clase con cuatro campos, pues sí y así lo deberías de hacer o no te solicitaron eso, que pasa que da pereza, pues no. Si nos piden eso, no inventes, cual sería en problema?

Creo que ninguno siguiendo los principios No vas a necesitarlo (YAGNI). En este caso si lo necesito.

Y para acreditar el resultado solo hay que mirar esto.

       1: SELECT 

       2: [Extent1].[Id] AS [Id], 

       3: [Extent1].[FechaFactura] AS [FechaFactura], 

       4: [Extent1].[Importe] AS [Importe], 

       5: [Extent2].[Nombre] AS [Nombre]

       6: FROM  [dbo].[Facturas] AS [Extent1]

       7: INNER JOIN [dbo].[Clientes] AS [Extent2] ON [Extent1].[ClienteId] = [Extent2].[Id]

Señores, eficiente.

Conclusiones.

Que ocurre que nos da miedo hacer join o que no sabemos, por que la moda es no enseñarlo. En este caso es más eficiente un join que cualquier otra cosa, lo puedes hacer con “Incluce” con “join” o como os he mostrado, simple.Pero utilízalo.

Un detalle que he dejado pasar por alto y quizá alguno se ha dado cuenta, en mi primer ejemplo de código escribí esto.

this.Configuration.LazyLoadingEnabled = false;

Efectivamente no utilices el Antipatrón o si lo haces conociendo lo que puede pasar, que ahorra poco, frente a una lectura explicita y cuando la necesito.

Buscando al culpable

2012-04-25T13:24:00Z

Os pongo en antecedentes Sql Azure no soporta transacciones distribuidas y para confirmarlo podéis leer esta entrada TransactionScope() in Sql Azure, o por lo menos con ese mismo escenario es con el que yo me he encontrado.

La aplicación está desarrollada utilizando los siguientes componentes.

Aplicación desarrollada en MVC3
Entity Framework 4.2
Sql Azure

Una de las reglas de negocio de esta aplicación es que a la entidad cliente se le debe de asociar un usuario, pues bueno que fue lo que hice, para no reinventar la rueda y puesto que MVC3 me dota de la posibilidad de utilizar MemberShip Provider.

Vamos a utilizar el metodo MemberShip.CreateUser y en la entidad Cliente creo una columna que sea un Guid y que haga referencia a este, aparentemente solucionado en un entorno de desarrollo, pero cuando hago el despliegue en Azure me encuentro con un magnífico error, que resumiendo me esta confirmando que este no soporta transacciones distribuidas.

Nos queda localizar quien es el culpable de este error y nos ponemos manos a la obra.

1. Transaction Scope. Primer descartado puesto que en otros puntos de la aplicación se está utilizando y no generaba ningún error.

2. MemberShip Provider. Para que TransactionScope cree una transacción distribuida una de las condiciones es que la cadena de conexión sea diferente. Así que vamos a confirmar que MemberShip no altera la cadena de conexión. Donde miramos? Pues en la propiedad Provider del objeto MemberShip y dentro de este en el campo privado _sqlConnectionString.

Esto lo podemos hacer de dos formas para el más friki con System.Reflection utilizando este código.

        1: var connectionStringField = Membership.Provider.GetType()

       2: .GetField("_sqlConnectionString", BindingFlags.Instance | BindingFlags.NonPublic);

       3:  

       4: var conexion = connectionStringField.GetValue(Membership.Provider);

Y para los que no tienen ganas de complicarse la vida que utilicen “inspección rapida” de visual studio o cualquier otro mecanismo yo utilizo este puesto que es rápido Shift+F9, bueno eso lo dejo a elección del consumidor.

Pues me parece que solo nos queda un candidato, será será EntityFramework, pues sí hemos acertado y por qué?.

3. EntityFramework. A partir de la versión 4.2 hace cosas por nosotros, que no se si las deberían de hacer pero sin preguntarlo agregan a nuestra cadena de conexión “Application Name=EntityFrameworkMUE” si esta en nuestro config no contiene “Application Name”. Y de verdad que no miento y para ello lo mejor es abrir con Reflector EntityFramework.dll y en el objeto InternalConnection localizamos un metodo estático que se llama.

“AddAppNameCookieToConnectionString”

No muestro el código completo pero si un aperitivo de lo que hace

       1: builder.ApplicationName = "EntityFrameworkMUE";

       2: connection.ConnectionString = builder.ToString();

       3: return connection.ConnectionString;

Redoble de tambores. a partir de la versión 4.2 EntityFramework es el causante de generar transacciones distribuidas, puesto que agrega a la cadena de conexión cosas sin nuestro permiso.

En esta otra entrada del foro de c# podéis encontrar opiniones de otras personas con las que coincido en su totalidad Transaction Scope y sobre todo lo que más me alegra es que en ese foro se muestre la solución a una respuesta que en otro con muchísimo prestigio se encuentre esto Using TransactionScope with Entity Framework code first and universal providers, no somos tan malos. Así que a participar, que entre todos podemos hacer que la cosa mejore

Solución.

Agregar a nuestra cadena de conexion en el config “Application Name=No me ayudes tanto que me gusta hacerlo a mi”

Conclusiones.

Sencillas.

1. Que MVC no debería incorporar MemberShip y mucho menos crear un Controlador AcountController con todo el mecanismo incorporado. Uno es abierto y fácil de configurar “MVC” y el otro es hermético como una lata, MemberShip. Por algo se creo en 2005.

2.Que le agradezco a EntityFramework todo lo que me ahorra, pero que no haga cosas de este tipo, que tenga yo la libertad de configurar lo que quiera y como quiera. A los señores del equipo yo les invitaría a tomarse unas vacaciones en conjunto con el equipo de MVC.

3. Que estamos en un momento en el que los cambios tan rápidos nos están haciendo caer en este tipo de cosas, detalles que son muy difíciles de resolver y que por tanto, con un poco más de calma quizá todos seamos más felices, quien produce y quien consume.

Entity Framework y los indices únicos.

2012-04-03T22:22:00Z

Ya me imaginaba yo que después de ver con Profiler las sentencias que genera con algún que otro problema nos íbamos a encontrar.

Vamos a plantearnos el siguiente problema, tenemos una entidad países con las siguientes propiedades.

        1: public class Pais

       2: {

       3:     public int Id { get; set; }

       4:     public string Nombre { get; set; }

       5:     public string Codigo { get; set; }

       6: }

Utilizando EF 4.3 y Migrations vamos a generar la tabla en la bb.dd y uno de los requerimientos es que “Codigo” sea único, si queréis ampliar temas de Migrations podéis visitar el blog de Javier Torrecilla. Yo os muestro el código tal y como lo he generado para crear la tabla.

       1: namespace WindowsFormsApplication1.Migrations

       2: {

       3:     using System.Data.Entity.Migrations;

       4:     

       5:     public partial class Paises : DbMigration

       6:     {

       7:         public override void Up()

       8:         {

       9:             CreateTable(

      10:                 "Pais",

      11:                 c => new

      12:                     {

      13:                         Id = c.Int(nullable: false, identity: true),

      14:                         Nombre = c.String(nullable:false,maxLength:50,unicode:false),

      15:                         Codigo = c.String(nullable: false, maxLength: 3, unicode: false),

      16:                     })

      17:                 .PrimaryKey(t => t.Id);

      18:  

      19:             CreateIndex("Pais", "Codigo", unique: true);

      20:             

      21:         }

      22:         

      23:         public override void Down()

      24:         {

      25:             DropTable("Pais");

      26:            

      27:         }

      28:     }

      29: }

Ahora vamos con nuestros requerimientos, en la tabla tenemos dos paises “España” y “Francia” que los podemos agregar con las siguientes instrucciones.

       1: using (Context ct = new Context())

       2: {

       3:     ct.Paises.Add(new Pais(){Nombre="España",Codigo="34"});

       4:     ct.Paises.Add(new Pais() { Nombre = "Francia", Codigo = "33" });

       5:     ct.SaveChanges();

       6: }

Y ahora nos dicen que lea la tabla Países y que cambie el código de “España a 33” y elimine “Francia” y de paso que inserte “China con código 35”.

Bueno pues sencillo

       1: using (Context ct = new Context())

       2: {

       3:     var paises = ct.Paises.AsEnumerable();

       4:     foreach (var pais in paises)

       5:     {

       6:         if (pais.Nombre == "Francia")

       7:         {

       8:             ct.Paises.Remove(pais);

       9:         }

      10:         else if (pais.Nombre == "España")

      11:         {

      12:             pais.Codigo = "33";

      13:         }

      14:     }

      15:     ct.Paises.Add(new Pais() { Nombre = "La China", Codigo = "35" });

      16:     ct.SaveChanges();

      17: }

Que ocurre que cuando ejecutamos nos encontramos con una sorprendente exception del tipo DbUpdateException, pero si miramos su InnerExceptión nos encontramos una SqlExceptión que nos dice lo siguiente.

“Cannot insert duplicate key row in object 'dbo.Pais' with unique index 'IX_Codigo'.”

Claro que ocurre que Entity Framework ejecuta primero “Update,Delete,Insert”, con lo cual yo siempre pensé que era “Delete,Update,Insert”, pero aún así en determinados escenarios nos podría ocasionar problemas.

Conclusiones.

Os voy a ser sincero, es un problema complicado de resolver, pero como dicen poder se puede, la verdad que no lo he probado con Merge, pero yo hasta ahora lo hacía de la siguiente forma.

Delete Tabla From, Update Tabla From, Insert Into Select y la verdad que os confieso que dormía bastante tranquilo, cosa que a partir de este momento no lo voy a hacer tanto.

Lanzo una pregunta ¿Os gustaría en linq que se pudieses ejecutar este tipo de sentencías?

Null. La Historia interminable 2/3

2012-04-03T12:08:00Z

Si recordamos el anterior Post, una de las frase que comente fue que desde el 2005 yo estaba libre de null y claro no hay que decirlo sino realmente demostrarlo y es por eso el motivo de esta entrada.

Lo primero que vamos a hacer es definir una interface que herede de IDataRecord y en ella definir unos métodos que nos permitan leer Nullables.

        1: public interface IDataRecordNullable : IDataRecord

       2: {

       3:     bool? GetNullBoolean(int i);

       4:     byte? GetNullByte(int i);

       5:     char? GetNullChar(int i);

       6:     DateTime? GetNullDateTime(int i);

       7:     Decimal? GetNullDecimal(int i);

       8:     double? GetNullDouble(int i);

       9:     float? GetNullFloat(int i);

      10:     Guid? GetNullGuid(int i);

      11:     Int16? GetNullInt16(int i);

      12:     Int32? GetNullInt32(int i);

      13:     Int64? GetNullInt64(int i);

      14:     string GetNullString(int i);

      15: }

Una vez definida nos toca implementarla para ello voy a definir una clase a la cual en el constructor le voy a pasar como parametro un IDataRecord.

Solamente voy a implementar una par de métodos y eso sí os dejo la tarea del resto por si alguien quiere vivir un poco más feliz.

       1: public class MyDataRecord : IDataRecordNullable

       2: {

       3:     private readonly IDataRecord DataRecord;

       4:     public MyDataRecord(IDataRecord DataRecord)

       5:     {

       6:         if (DataRecord == null)

       7:         {

       8:             throw new ArgumentNullException();

       9:         }

      10:         this.DataRecord = DataRecord;

      11:     }

      12:     public int GetInt32(int i)

      13:     {

      14:         return DataRecord.GetInt32(i);

      15:     }

      16:     public int? GetNullInt32(int i)

      17:     {

      18:         if (IsDBNull(i))

      19:             return null;

      20:         return GetInt32(i);

      21:     }

      22: }

A partir de este momento la cosa se hace más agradable simplemente lo que tengo que hacer es utilizar esa clase para leer mis datos tal y como os muestro.

       1: using (SqlConnection cn = new SqlConnection(@"Tu conexion"))

       2: {

       3:     cn.Open();

       4:     string sql = @"SELECT CAST(NULL AS INT) NUMERO,CAST(NULL AS VARCHAR(50)) 

       5:                 CADENA UNION ALL SELECT CAST(1 AS INT),CAST('HOLA' AS VARCHAR(50)) ";

       6:     SqlCommand cmd = new SqlCommand(sql, cn);

       7:     SqlDataReader rd = cmd.ExecuteReader();

       8:                 

       9:     MyDataRecord reader = new MyDataRecord(rd);

      10:  

      11:     while (rd.Read())

      12:     {

      13:         int? numero = reader.GetNullInt32(0);

      14:         string Cadena = reader.GetNullString(1);

      15:     }

      16: }

Como podéis observar sencillo y por fin me puedo librar de utilizar este código una y otra vez.

       1: int? numero = rd.IsDBNull(0) ? null : rd.GetInt32(i);

El ejemplo es útil para cualquier versión del framework a partir de la 2.0, pero claro os voy a dar una idea, para los más modernos, entre los que me incluyo. Porque no utilizamos Extension Methods y podemos hacer lo mismo sin tener que crear un nuevo objeto cuando voy a leer.

Vamos con ello.

       1: public static class ExtensionDbDataReader

       2: {

       3:     public static int? GetNullInt32(this DbDataReader reader,int i)

       4:     {

       5:         if (reader.IsDBNull(i))

       6:             return null;

       7:         return reader.GetInt32(i);

       8:     }

       9: }

Como veis ya no tengo que ir instanciando mi clase sino simplemente al utilizar un Extension Methods me encuentro con un método extensor en cualquiera de las clases que heredan DbDataReader, jo sin quererlo como que me sirve para cualquier motor de bb.dd.

Bueno os dejo una tarea, que es implementar 11 métodos para cada uno de los tipos primitivos y uno para el maldito “string”. Y ahora voy con ese, que se quedo en el tintero en el anterior post.

Si analizamos nuestras aplicaciones un porcentaje muy alto de nuestras propiedades son string concretamente en una app de aproximadamente unas 500 tablas y 3800 columnas 2500, son varchar o sus derivados, es decir el 66%. Todas ellas no tienen otra representación en el CLR que no sea un string y claro a este se le puede asignar null y no dice nada, hasta que llega a la bb.dd que si la columna no permite null esta si va a decir y además cosas feas.

Pues hasta el momento solamente nos queda una solución y es bastante tediosa, algo parecido a implementar en nuestras clases INotifyPropertyChanged o bien decorarlas con atributos de System.ComponentModel.DataAnnotations dependiendo de la tecnología que utilicemos en nuestras vistas, ambas de verdad para mí feas, pero feas.

Vamos a solucionar el problema de todos los string que no permiten nulos o por lo menos como yo lo he hecho hasta el momento.

       1: public class Entidad

       2: {

       3:     public int Id { get; set; }

       4:     string _Nombre;

       5:     public string Nombre

       6:     {

       7:         set

       8:         {

       9:             _Nombre = value;

      10:         }

      11:         get

      12:         {

      13:             return _Nombre ?? string.Empty;

      14:         }

      15:     }

      16: }

Como no solamente de leer vive el hombre y a veces nos toca escribir, cuando queremos guardar un valor null en la bb.dd, también tenemos que tener en cuenta alguna que otra cosa y es que no podemos enviar null sino System.DbNull.Value, esto es más sencillo y un poco más corto, simplemente vamos a crear un Extension method para SqlParameterCollection tal y como os muestro.

       1: public static class ExtensionDbParameterCollection

       2: {

       3:     public static SqlParameter AddValueWithNull(this SqlParameterCollection Parameters,string ParameterName,SqlDbType Type,int Size, object Value )

       4:     {     

       5:         var Parametro =  Parameters.Add(ParameterName, Type, Size);

       6:         Parametro.Value = (Value == null) ? System.DBNull.Value : Value;

       7:         return Parametro;

       8:     }

       9: }

Como podéis observar lo he implementado para SqlServer el resto de servidores os lo dejo a vosotros y una cosa importante no utilizar AddWithValue, en esta entrada del foro de c# podéis ver los motivos.

SqlParameterCollection.AddWithValue Method.

Para terminar y como se que alguno va a decir ¿porque no utilizas generic y te ahorras esos 11 métodos y el maldito? Pues sencillo porque me obliga a hacer cast en cada una de las lecturas y menos óptimo puede ser cualquier cosa y más si leemos muchos registros, de todas formas os dejo ese método con generic. Pero ya os he advertido de las consecuencias .

       1: public static class ExtensionDbDataReader

       2: {

       3:     public static Nullable<T> GetNullValue<T>(this DbDataReader Reader, int i) where T:struct

       4:     {

       5:         if (Reader.IsDBNull(i))

       6:             return null;

       7:         return (T)Reader.GetValue(i);

       8:         

       9:     }

      10: }

Saludos y a implementarlo.

Null.La historia interminable(1/3)

2012-03-27T14:07:00Z

Esta mañana y después de ver esta entrada en el foro de c# Obtener los registros de una tabla como objetos y guardarlos en una lista y más concretamente estas líneas de código.

        1: object fechaNacim = reader["FechaNacim"];

       2: FechaNacimiento = fechaNacim == DBNull.Value ? null : (DateTime)fechaNacim;

Me han llegado a la cabeza recuerdos del pasado, mucho antes de la existencia de .Net. Os acordáis de ese error típico de las aplicaciones vb “error 91 object variable or with block variable not set”. Y después muerte. Pues ha llovido, pero lo seguimos teniendo presente en nuestras vidas.

Después de citar al viejo vb donde esto se solucionaba con esto

       1: if isnull(ADODC.Recordset.Fields("Cod_Localidad")) then

       2: end if

avanzamos en el tiempo y nos encontramos en la misma o parecida situación un null de la bb.dd nos ocasiona y no pocos problemas.

Si nos situamos en el año 2002 aparece un nuevo señor para solucionarnos el problema DBNull.Value, que pasada. Ya no aparece el error 91 pero si FormatException.

       1: var ValorBd = System.DBNull.Value;

       2: int Valor = int.Parse(ValorBd.ToString())

Y también SqlNullValueException.

       1: using (SqlConnection cn = new SqlConnection(@"<Cadena de Conexion>"))

       2: {

       3:        cn.Open();

       4:        SqlCommand cmd = new SqlCommand("SELECT CAST(NULL AS INT)",cn);

       5:        SqlDataReader reader = cmd.ExecuteReader();

       6:        while(reader.Read())

       7:        {                    

       8:            int Valor = reader.GetInt32(0);

       9:        }

      10: }

y en vez de tener un premio que era lo que se conseguía antes de .Net obtenemos dos.

Bueno como una de nuestras virtudes es la paciencia esperamos a 2005 y aparece una de las maravillas del Framework 2.0 System.Nullable<T> o para quien más le guste “?” detrás del tipo, parece que el problema está solucionado, pero no, simplemente con profundizar un poco nos damos cuenta que las clases del namespace System.Data se han quedado igual y es por eso por lo que esta mañana para leer un null nos encontramos con las primeras líneas de código de este post.

Seguimos avanzando años y vemos que ese problema parece que se va a convertir en un mal menor con la aparición de Entity Framework y la realidad que así es, pero sigue sin ser perfecto.

Si reflexionamos han pasado por lo menos para mí 20 años y seguimos pensado en Null.

Bueno he de reconocer que desde 2005 yo deje de pensar en el y eso es material para el próximo post o mejor dicho un capitulo más de esta historia.

Próximos capítulos.

Como puedo vivir mejor con Null sino utilizo Entity Framework.

Que le falta a EF desde mi punto de vista para de una vez olvidarnos del Null.

Como una de las cosas que más me gusta es el debate vamos a empezar con un aperitivo. ¿Debería string tener un tipo Nullable o lo que es lo mismo declarar este como “?string” ?

Espero que os haya gustado y sobre todo espero vuestra reflexión acerca de la pregunta.

Utilizando razor para generar un csv

2012-03-22T14:42:00Z

En muchos de nuestros desarrollos nos solicitan la funcionalidad de exportar nuestros datos a diferentes formatos y hoy me ha tocado exportar a csv.

Lo lógico, es que lo hubiese hecho de la forma tradicional simple y sencillo defino un StringWriter y un foreach hasta que acabe,pero los años me están haciendo despertar la imaginación,con lo cual he pensado en hacerlo de otra forma.

¿Cómo?.Voy a utilizar una vista que se encargue de generar el csv.

Manos a la obra.

Partimos para el ejemplo de un modelo sencillo una factura con las siguientes propiedades Número,Fecha e Importe.

using System;
using System.Collections.Generic;
using System.Linq;


namespace MvcApplication15.Models
{
    public class Factura
    {
        public int Id { get; set; }
        public DateTime FechaFactura { get; set; }
        public Decimal Importe { get; set; }
    }
}

Lógicamente el segundo paso es crear un controlador y un método dentro de él que nos permita solicitar el csv.

Que tengo que hacer, pues retornar un FileContentResult con MimeType “text/csv”.

public ActionResult GetCsv()
{
    //Generamos RazorViewEngine
    var razorView = new RazorViewEngine();
    var viewEngineResult = razorView
             .FindPartialView(ControllerContext, "_GetCsv", false);

    //Creamos la vista y pasamos el modelo
    var modelo = new List<Factura>()
    {
        new Factura(){Id=1,
                      FechaFactura = DateTime.Now.Date,
                      Importe = 1000},

        new Factura(){Id=1,
                      FechaFactura = DateTime.Now.AddDays(1).Date,
                      Importe = 2000}
    };
    var vista = View(viewEngineResult.View, modelo);

    //Renderizamos la vista
    using (StringWriter sw = new StringWriter())
    {
        var viewContext = new ViewContext(
            ControllerContext, 
            vista.View, 
            vista.ViewData, 
            vista.TempData, sw);
        
        vista.View.Render(viewContext, sw);
        
        var result = Encoding.UTF8.GetBytes(sw.ToString());
        
        viewEngineResult.ViewEngine
            .ReleaseView(ControllerContext, vista.View);
        
        return File(result, "text/csv", "facturas.csv");
    }
            

}

y por último tenemos que definir nuestra vista y solicitar nuestro archivo desde el explorador.

@model IEnumerable<MvcApplication15.Models.Factura>
@{
<text>Numero;Fecha;Importe</text>
}
@foreach (var item in Model)
{
<text>@item.Id;@string.Format("{0:dd/MM/yyyy}", item.FechaFactura);
      @string.Format("{0:###,###,##0.00}", item.Importe)</text>    
}

Nota: todo el texto que que se escribe dentro de las etiquetas <text>

debe de estar en una sola línea.

Conclusiones.

Pues sencillo que MVC nos deja hacer escapar nuestra imaginación hasta límites insospechables, gracias a ser un framework abierto crece y crece o lo podemos hacer crecer .

Espero que os guste y sea de utilidad.

Mis Agradecimientos

2012-03-15T21:52:00Z

Hola, lo normal en estos casos es presentarse con esas cosas bonitas que a todos nos dejan estupendamente frente a los demás,pero a parte de eso, que no dudéis, que lo voy a hacer intentaré con esta presentación escribir algo que empiece a ser útil.

Bueno mis agradecimientos.

Jo a quien, pues primero al que te autoriza a escribir en este magnifico sitio Rodrigro Corral, Muchísimas gracias Rodrigo.

Lluis Franco, me es imposible poner todos tus links porque al final va a parecer que estás escribiendo tú, pero bueno todos te conocen y cito este porque si alguien entra a mi blog que no se pierda esa magnifica serie que estás escribiendo sobre Parallel Series y de paso alguien podrá leer ese Maestro de Maestros . Muchísimas gracias Lluis.

Bueno esto sería interminable pero quiero citar a personas con las que en twitter comparto risas y buenos momentos @Jtorrecilla,Eduard Tomas(@eiximenis),Luis siempre estás programando y haciendo cenas:), todos ellos tienen como maestros que son, no es que yo me considere, blog’s en geeks.

Bueno y la verdad que no me puedo olvidar de la comunidad, a todos los que me aguantáis diariamente en los foros de msdn y más concretamente en el foro de c# donde gracias a Leandro soy administrador. Leandro gracias.

No me podía olvidar de dos personas con las que comparto muchas horas y que siempre me han alentando a escribir. Escribe, escribe… Luis Y Ramirez y mi amigo del pajarito Nicoloco.

La verdad que soy un pelota, pero llevo una hora buscando todas las url’s para hacer publicidad con lo cual señores estámos en Marzo así que quiero caramelos por semana santa porque "jamón del norte" no me mandan.

Sabía yo que alguien me dejaba en el tintero, esa persona que actúa como tu padre y te dice, céntrate, constancia ,etc . no sabéis quien es? mi gran amigo Salvador Ramos.

Y ahora toca contar un poco de mi historia durante un montón de años estoy ligado al desarrollo de aplicaciones empresariales, de esas que no tienen una entidad, ni dos, ni tres ,sino 500 o más y lo lógico es que tengas que pensarlas de forma muy detallada y examinando hasta el último ;.

Es por eso que hace tiempo leí este post Preventing SQL Injection with the Entity Framework and Data Services y como no me puse a probar y a jugar un poco con esa realidad.

Voy a realizar las pruebas que hice, Aunque os las voy a pasar con Entity Framewoek 4.3.1 o como se llame en el futuro, eso si CodeFirst, me gusta

1. Vamos a definir un modelo sencillo una entidad y no 500

public class Entidad
    {
        public int Id { get; set; }        
        public string Nombre { get; set; }
    }

    public class Context : DbContext
    {
        

        public DbSet<Entidad> Entidad {get;set;}
            
        
    }

Vamos con la primera prueba

 using (Context ct = new Context())
            {

                var resultado = ct.Entidad.Where(c => c.Nombre == "Hola");
                foreach (var entidad in resultado)
                {

                }
                
            }

El resultado es el esperado me da la impresión que si es vulnerable no esta presente sp_executesql y genera una cadena .

SELECT 
[Extent1].[Id] AS [Id], 
[Extent1].[Nombre] AS [Nombre]
FROM [dbo].[Entidads] AS [Extent1]
WHERE N'Hola' = [Extent1].[Nombre]

bueno pues vamos a intentar que por lo menos a nadie se le ocurra escribir variable.ToString() , creo que es fácil educar al equipo .

Con lo cual vamos a ejecutar la siguiente prueba

var variable = "Hola";           
using (Context ct = new Context())
{

        var resultado = ct.Entidad.Where(c => c.Nombre == variable.ToString());
         foreach (var entidad in resultado)
         {

          }
                
 }

Y cual fue mi gran sorpresa, pues sencillo una enorme satisfacción al encontrarme con una exceptión del tipo NotSupportedException con el mensaje “LINQ to Entities no reconoce el método 'System.String ToString()' del método, y este método no se puede traducir en una expresión de almacén”.

Y eso , por que? Pues buscando pronto me encontré con esto Asignar método CLR a función canónica y que suerte ToString() no está soportado.Me di cuenta que lo que decía el post era verdad. Estas funciones están en el namespace System.Data.Objects.SqlClient y concretamente expuestas como métodos estáticos de la clase SqlFunction.

Espero que os haya gustado, hasta el próximo.