Will my Dynamic Entities kill Code Generation ?

Inspired always by code generation. I have been exploring Generics and how to end this misery.

I am very close on this one and although working is not quite the ultimate morphic entity we dream of

but an almost dynamic DTO that is cacheable. My contribution to the originating author here is caching DTO’s by callable name & it is working quite brilliantly. Even better there are no second trips to the database.

A must here in the real world !!!

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

namespace DynamicEntities.DTOHelpers
{
public interface IDTO<BE>
{
BE BusinessEntity
{
get;
set;
}
}

[Serializable()]
internal sealed class DTO<BE> : IDTO<BE>
{
private BE businessEntity;

public BE BusinessEntity
{
get { return businessEntity; }
set { businessEntity = value; }
}
}
}



using System;
using System.Collections;
using System.Xml.Serialization;
using System.IO;
using System.Web;

namespace DynamicEntities.DTOHelpers
{
public sealed class DTOStore<BE>
{
private static Hashtable dtoRegister = null;
private static readonly object lockObj = new object();
private static int key = -1;

private DTOStore()
{

}

public IDTO CreateDTO()
{
IDTO dto = new DTO();
return dto;
}

public IDTO GetDTO(int key)
{
lock (dtoRegister.SyncRoot)
{
if (dtoRegister.ContainsKey(key))
return (IDTO)dtoRegister[key];
}
return null;
}

public IDTO GetDTO(string name, HttpContext ctx)
{
int key = System.Convert.ToInt32(ctx.Session[name]);
lock (dtoRegister.SyncRoot)
{
if (dtoRegister.ContainsKey(key))
return (IDTO<BE>)dtoRegister[key];
}
return null;
}

public bool RegisterDTO(IDTO dtoObject)
{
if (dtoRegister.ContainsKey(dtoObject.GetHashCode()))
{
return false;
}

lock (dtoRegister.SyncRoot)
{
dtoRegister.Add(dtoObject.GetHashCode(), dtoObject);
key = dtoObject.GetHashCode();
}

return true;
}

public bool RegisterDTO(IDTO dtoObject, string name, HttpContext ctx)
{
if (dtoRegister.ContainsKey(dtoObject.GetHashCode()))
{
return false;
}

lock (dtoRegister.SyncRoot)
{
dtoRegister.Add(dtoObject.GetHashCode(), dtoObject);
key = dtoObject.GetHashCode();
ctx.Session.Add(name, key);
}

return true;
}

public bool UnRegisterDTO(int key)
{
if (dtoRegister.ContainsKey(key))
{
lock (dtoRegister.SyncRoot)
{
dtoRegister.Remove(key);
key = -1;
return true;
}
}
return false;
}

public bool UnRegisterDTO(string name, HttpContext ctx)
{
int key = System.Convert.ToInt32(ctx.Session[name]);
if (dtoRegister.ContainsKey(key))
{
lock (dtoRegister.SyncRoot)
{
dtoRegister.Remove(key);
key = -1;
return true;
}
}
return false;
}

public static int Key
{
get
{
return key;
}
}

public static DTOStore<BE> Instance
{
get
{
lock (lockObj)
{
return Nested.dtoStore;
}
}
}

internal class Nested
{
static internal readonly DTOStore dtoStore = new DTOStore();

static Nested()
{
dtoRegister = Hashtable.Synchronized(new Hashtable());
}
}
}
}

Advertisements

One comment

  1. Well no.. but it was a really sophistacated way of Loading and caching DTO’s.

    Pretty cool excersize nonetheless. You could go two directions with these Dynamic DTO’s

    but an Entity View Produces the same result and is accessible via DataContext.

    The call and construct for the above was pretty turse. This ialso a good case for

    Abstraction which may have been the only thing lacking here. I may revist this when

    doing some work with IObservables.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s