For this purpose Microsoft provides some classes:

• CreateDatabaseIfNotExists
• DropCreateDatabaseAlways
• DropCreateDatabaseIfModelChanges

All classes implement interface IDatabaseInitializer<T> where T is a DbContext.

For example if you want populate database with base informations before execute
an unit test you can write code like this:

public class MyTestIntializer : DropCreateDatabaseAlways<MyContext>
{
  protected override void Seed( MyContext context )
  {
      var categories = new Lists<Category>();
      var products = new Lists<Product>();

      categories.Add( new Category { Name = "tech" } );
      categories.Add( new Category { Name = "food" } );

      products.Add( new Product { Name = "cpu", Category = categories[0] } );
      products.Add( new Product { Name = "harddisk",
                          Category = categories[0] } );
      products.Add( new Product { Name = "biscuits",
                          Category = categories[1] } );

      addToContext<Category>( context, categories );
      addToContext<Product>( context, products );
  }

  private void addToContext<T>( MyContext context, IList collection )
  {
      foreach( var item in collection )
      {
          context.Set<T>().Add( item );
      }
   }
}

This data initializer drop (if exists) and create database and finally populate it with
categories and products.

Now we can add it to our test class.

[ClassInitialize()]
public static void MyClassInitialize( TestContext testContext )
{
    Database.SetInitializer<MyContext>( new MyTestIntializer() );
}

For instance, if you are using AutoFac you can write code like this:

public class AutoFacDependencyResolver : IDependencyResolver
{
   readonly IContainer _container;
   public AutoFacDependencyResolver ( ContainerBuilder builder )
   {
      this._container = builder.Build();
   }
   public object GetService( Type serviceType )
   {
      try
      {
         return _container.Resolve( serviceType );
      }
      catch { return null; }
   }

   public IEnumerable GetServices( Type serviceType )
   {
      try
      {
         var enumerableType = typeof( IEnumerable ).MakeGenericType( serviceType );
         return _container.Resolve( enumerableType ) as IEnumerable;
      }
      catch { return null; }
   }
}

Now, it’s easy to register your types and what should resolver use:

protected void Application_Start()
{
   // register type
   var containerBuilder = new ContainerBuilder();
   containerBuilder.RegisterType().As();

   // set resolver
   DependencyResolver.SetResolver(
      new AutoFacDependencyResolver( containerBuilder ) );
}

What can we do with MongoLab-Rest-Client? Today all crud operations on our entities.

Steps:
1) Sign up to http://mongolab.com
2) Get the apikey ( ex. 123456789012345678901234 )
3) Write code:

var client = new MRestClient( “mydb” );
client.Apikey = “12345678901234567890123″;

// store a new entity
var obj = new Product();
var result = client.Create( obj );

// make a query using criteria api
var criteria = new Criteria();
criteria.Add( Restriction.Or
.Add( Restriction.Eq( “Name”, “name1″ ) )
.Add( Restriction.Eq( “Name”, “name2″ ) ) )
.Add( Restriction.Lte( “Quantity”, 2 ) );
IList products = client.GetByCriteria( criteria );

Only easy C# code and without define a schema on database.

AppHarbor gestisce sia il deployment che la fase di runtime delle applicazioni .net.
E’ possibile fare il push del codice, in pratica, da tutti i vcs e dvcs oggi disponibili (git, mercurial, svn, tfs…), AppHarbor farà la build, lancerà i nostri test e se questi daranno esito positivo farà il deployment sull’application server e noi sviluppatori riceveremo tutte le notifiche.

In fase di esecuzione AppHarbor gestirà la scalabilità dell’applicazione (possiamo acquistare più istanze) e il bilanciamento del carico delle richieste.

Una caratteristiche che mi piace molto è l’estendibilità della piattaforma, in quanto AppHarbor mette a disposizione delle api per consentirci di sviluppare nuovi add-on come ad esempio supportare un nuovo vcs o un nuovo sistema di notifiche.

Una chicca è il catalogo degli add-on (in continua crescita) per “pluggare” servizi nelle nostre applicazioni come dbms (sqlserver,mysql,mongodb,redis) o gestiori di log (airbrake), un vero e proprio store di servizi per le applicazioni.

Per chi vuole cominciare a provarlo i prezzi mi sembrano competitivi e la prima istanza è gratis.

namespace LegacyDomain
{
 public class Building
 {
   public int Id { get; set; }
   public IList Resources { get; set; }
   //.....
 }

 public class Resource
 {
   public int Id { get; set; }
   public byte[] Bytes { get; set; }
   public ResourceType RType { get; set; }
  }

  public enum ResourceType { SmallPhoto, BigPhoto }
}

namespace DTO
{
 public class BuildingDTO
 {
   public int Id { get; set; }
   public int SmallPhotoId { get; set; }
   public int BigPhotoId { get; set; }
 }
}

Mapper.CreateMap()
      .AfterMap( ( i, d ) => d.SmallPhotoId = i.Resources
         .Where( r => r.RType == ResourceType.SmallPhoto )
         .Select( r => r.Id ).SingleOrDefault() )
      .AfterMap( ( i, d ) => d.BigPhotoId = i.Resources
         .Where( r => r.RType == ResourceType.BigPhoto )
         .Select( r => r.Id ).SingleOrDefault() )

Per intervenire su questi aspetti ci basterà fare l’override del metodo OnModelCreating del nostro DbContext:

public class ADMDbContext : DbContext
{
        public DbSet<User> Users { get; set; }
        public DbSet<Role> Roles { get; set; }

        protected override void OnModelCreating( DbModelBuilder modelBuilder )
        {
            modelBuilder.Entity<User>().ToTable( "Users" );

            modelBuilder.Entity<User>().HasKey( o => o.Id );
            modelBuilder.Entity<User>().Property( o => o.UserName ).IsRequired();

            modelBuilder.Entity<Role>().HasKey( o => o.Id );
            modelBuilder.Entity<Role>().Property( o => o.Name ).IsRequired();

            base.OnModelCreating( modelBuilder );
        }
}

La versione 4.1 di EF, introduce il nuovo modello di sviluppo code-first, che si affianca alle altre due modalità model-first e database-first, già presenti nella precedente versione.
Personalmente trovo il nuovo approccio code-first più vicino al mio modo di sviluppare codice, in quanto ho delle preferenze per lo sviluppo DDD (Domain Driven Development).

In pratica la prima cosa che faccio quando inizio un nuovo progetto è quello di definire le entità che meglio modellano lo scenario (attraverso la scrittura di classi C#) in cui dovrà operare l’applicazione che dovrò realizzare, senza dovermi preoccupare (inizialmente) di come queste debbano essere persistite. Dal punto di vista del codice.

public class User
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
}

L’unico overhead aggiunto da EF 4.1 è la definizione di una classe che estenderà DbContext, la quale rappresenta in punto d’ingresso per gestire la persistenza delle entità. Ad esempio:

public class MyContext : DbContext
{
public DbSet<User> Users { get; set; }
}
Finito!

Nessun database creato, nessuna tabella definita.

Adesso ci basterà scrivere una normale query Linq per recupare i dati dal database:

var ctx = new MyContext();

var query = from o in ctx.Users select o;

var users = query.ToList();

Cosa è successo?

Semplicemente (si fa per dire), al momento dell’esecuzione del metodo ToList() il motore di EntityFramework genererà per noi un database (sql server) con il nome MyContext e le tabelle necessarie a persistere le classi definite come DbSet nella classe MyContext, infone verrà effettuata la query T-Sql generata dal provider Linq dell’Entity Framework.

Il manifesto del gruppo:

+——————————————————–

it.comp.dotnet
Infrastruttura, linguaggi, framework e strumenti relativi alle
implementazioni della Common Language Infrastructure

+——————————————————–

Il gruppo it.comp.dotnet e` dedicato alle discussioni attinenti lo standard
ISO/IEC 23271 in tutte le sue implementazioni, le tecnologie ad esso
correlate e lo sviluppo di applicazioni basate su tale standard.

Sono, quindi, incluse le discussioni riguardanti i seguenti argomenti:
+ varie implementazioni dello standard (framework .NET, MONO…);
+ compilatori;
+ linguaggi (C#, VB.NET…);
+ ambienti di sviluppo (Visual Studio, MonoDevelop…);
+ piattaforme di sviluppo, librerie di classi, tecnologie varie inerenti
(WPF, WCF, ASP.NET, AJAX, ADO.NET, Castle, NUnit, Rhino, NHibernate …)
+ strumenti e tecnologie accessorie allo sviluppo (MSBuild, CCNet, Nant,
…)
Sono anche da considerarsi comprese le discussioni riguardanti la
migrazione verso .NET da altre tecnologie e viceversa.