ConfORM : DDD API, Proposals ?

The ConfORM architecture allows a substitution of the “mapping-elements-drive”.

In the actual implementation I’m using a class named ObjectRelationalMapper where I’m using ORM terminology:

public interface IObjectRelationalMapper
{
   void TablePerClass(IEnumerable<Type> baseEntities);
   void TablePerClassHierarchy(IEnumerable<Type> baseEntities);
   void TablePerConcreteClass(IEnumerable<Type> baseEntities);
   void TablePerClassHierarchy<TBaseEntity>() where TBaseEntity : class;
   void TablePerClass<TBaseEntity>() where TBaseEntity : class;
   void TablePerConcreteClass<TBaseEntity>() where TBaseEntity : class;
  
   void Component<TComponent>();
   void Complex<TComplex>();

   void Poid<TEntity>(Expression<Func<TEntity, object>> propertyGetter);
   void ManyToMany<TLeftEntity, TRigthEntity>();
   void ManyToOne<TLeftEntity, TRigthEntity>();
   void OneToOne<TLeftEntity, TRigthEntity>();
   void Set<TEntity>(Expression<Func<TEntity, object>> propertyGetter);
   void Bag<TEntity>(Expression<Func<TEntity, object>> propertyGetter);
   void List<TEntity>(Expression<Func<TEntity, object>> propertyGetter);
   void Array<TEntity>(Expression<Func<TEntity, object>> propertyGetter);
   void Dictionary<TEntity>(Expression<Func<TEntity, object>> propertyGetter);

   void Cascade<TFromEntity, TToEntity>(Cascade cascadeOptions);
  
   void PersistentProperty<TEntity>(Expression<Func<TEntity, object>> propertyGetter);
}

I would read some proposal for a IDddMapper.

For example

• instead “Component” use “ValueObject”
• instead define the cascade behavior between two classes use AggregateRoot
• Add …
• …

Have you a proposal with a little explication of the expected behavior ?