我有我的同事繼承的業務邏輯操作的基類。這個類暴露了一個構造函數,它需要一個objectContext
作爲參數。您可以將此基類視爲原子CRUD操作的組件(其所有select,insert,edit和delete方法將始終只對一個實體起作用)。對象共享和動態實例創建
然後,我有一個「超類」,其主要目的是在上述所有基類之間共享objectContext
以執行某些業務事務,並且必須提供任何baseClass
實例。
所以,我在找一個優雅的方式來「注入」超類的objectContext
成baseclass
:
public BaseClass<T> where T : entity
{
private ObjectContext _ctx;
public BaseClass(ObjectContext ctx){ _ctx = ctx;}
public virtual IList<T> Select(){..}
public cirtual voind Insert(T entity){..}
// other stuff
}
public class SuperClass
{
private ObjectContext _ctx = new...
public BaseClass<TEntity> LoadBaseClass(TBase, TEntity) where TBase : BaseClass<TEntity>, where TEntity : class
{
BaseClass<TEntity> obj = Activator.CreateInstance(typeof(TBase), _ctx); // share objectContext
}
public int SaveAll(){return _ctx.SaveChanges();}
}
正如你看到的,我的超類是能夠通過其類型,返回一些baseClass
實例,這正是我想要的。但是,如果某些繼承類使用其他參數定義自己的構造函數,則我的方法將失敗。
我會找到一個乾淨的解決方案,以避免從LoadBaseClass
方法實例創建期間出現任何錯誤的可能性。我知道的唯一方法是定義一個私人構造器,但通過這種方式,沒有人能夠繼承baseclass
了。
這是不可能完成我的應用程序。我的應用程序有點複雜,你怎麼想象..我在不同的數據庫上使用多個objectContex,我希望讓同事免費構建UnitOfWork和商業類,他們更喜歡。 – bit
依賴注入用於各種應用程序,但主要用於更復雜的應用程序。使用您當前的解決方案,您正嘗試構建一些依賴注入容器已經爲您完成的工作。我強烈建議您閱讀一些DI文檔,以確保它不符合您的需求。 –
當然,DI可能是許多情況下的一個很好的解決方案,但我認爲它不適合我的情況。我會記住你,ObjectContext不一定在businessClass之間共享。事實上BL類可以自己生活。共享需求只取決於我的同事建立他們的邏輯。我想要做的是爲原子核和交易操作提供一個「基礎」組件。 – bit