In my project I have two class, Role and User:

public class Role
{
    public Guid Id { get; set; }
    public string Name { get; set; }
}

public class User
{
     IList<Role> _role;

     public virtual IList<Role> Roles
     {
        get { return _role ?? ( _role = new List<Role>() ); }
     }

     public Guid Id { get; set; }

     public string UserName{ get; set; }
     public string FirstName { get; set; }
     public string LastName { get; set; }
}

If you want create custom configuration for User and Role, you can write others two class that works as configuration, RoleConfigration and UserConfiguration that extend EntityTypeConfiguration:

// custom configuration for Role
public class RoleConfiguration : EntityTypeConfiguration<Role>
{
     public RoleMapping()
     {
         ToTable( "Roles" ); // ef will create a table with name Roles
         HasKey(o => o.Id);  // define a key
         Property( o => o.Name ).IsRequired(); // this property is required on repository
     }
}

// custom configuration for User
public class UserConfiguration : EntityTypeConfiguration<User>
{
    public UserMapping()
    {
         ToTable( "Users" ); // ef will create a table with name Users
         
         HasKey(o => o.Id);  // define a key
         // the property is required on repository
         Property( o => o.UserName ).IsRequired(); 
         // this property is nullable and map on column with name firstname
         Property( o => o.FirstName ).HasColumnName("firstname");
         // this property is nullable and map on column with name lastname
         Property( o => o.LastName ).HasColumnName("lastname"); 

         // configure many-to-many navigation property between
         // User and Role
         HasMany( o => o.Roles ).WithMany();
    }
}

Now, for use our custom configuration, we will simply add RoleConfiguration and UserConfiguration to DbContext:

public class MyDbContext : DbContext
{
    public virtual IDbSet CreateSet()
         where TEntity : class
    {
        return Set();
    }

    protected override void OnModelCreating( DbModelBuilder modelBuilder )
    {
        modelBuilder.Configurations.Add( new RoleConfiguration() );
        modelBuilder.Configurations.Add( new UserConfiguration() );

        base.OnModelCreating( modelBuilder );
    }
}

Hope this helps,
Tony

Si proprio lei la nostra cara “vecchia email” gioie e dolori di molti dipendenti.

Trovare decine di email da leggere, nella propria casella di posta, può far perdere molto tempo, anche perché molte sono li per  eccesso di scrupolo  da parte di chi le ha inviate, tanto una email in più non fa mai male.

Questo spam a fin di bene  è principalmente un problema organizzativo e gli effetti dannosi di tale pratica sono direttamente proporzionali alla dimensione delle organizzazioni stesse.

Occorrerebbe forzare le persone a pensare prima di inviare una mail, rispondendo ad una domanda del tipo:

Qual è il contesto informativo a cui si rivolge questa mail?

Rispondere a questa domanda può non essere semplice, per questo ho iniziato a lavorare ad una progetto software il cui obiettivo è quello di migliorare il modo con cui avviene la comunicazione all’interno di una organizzazione.

L’idea di base è quello di contestualizzare i messaggi che il mittente invia senza dover dichiarare esplicitamente i diretti destinatari degli stessi, ma piuttosto di indicare di cosa tratta il messaggio che stiamo inviando.
Un messaggio così fatto sarà inviato ad un servizio software il quale, in base alle informazioni in suo possesso, deciderà chi sono i destinatari.

Un esempio di nuovo messaggio può chiarire l’idea:

from: Antonio Di Motta
to: <myorg>.process.new
message body:
La presente è per informarvi che è stato rilasciato un nuovo processo aziendale relativo alla gestione delle stampanti aziendali…

Il servizio software avrà a disposizione un indice interno del tipo:

<myorg>.process.* => employee1, employee2
<myorg>.process.new => employee3
<myorg>.process.change => employee4
…….

Dopo aver consultato l’indice, il messaggio verrà inoltrato ad employee1, employee2 e employee3, ma non ad employee4 in quanto risulta interessato solo ai cambiamenti dei processi aziendali già presenti.

Un software di questo tipo può essere classificato come Message Context System (MCS) e garantisce l’invio solo dell’email necessarie, in quanto costringerebbe gli autori a riflettere su quale sia l’ambito informativo da considerare e di conseguenza imporre una organizzazione alle comunicazioni interne.

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<MyConcreteClass>().As<IMYInterface>();

   // 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.