所以我很高兴在我的AddIn中使用3层架构,但是在我的VSTO中实现它有问题(也许我不应该这样做?)。无论如何,这是我的非工作解决方案;
我的VSTO有一个接收所有对象的按钮。
private void Bt1_Click(object sender, Microsoft.Office.Tools.Ribbon.RibbonControlEventArgs e)
{
ObjectManager objManager = new ObjectManager(new ExcelObjectDal());
var allObjects = objManager.GetObjects();
//Add all objects to WinForm
}和我的ObjectManager,位于我的业务层中:
public class ObjectManager : IObjectService
{
public IObjectDal ObjectDal { get; set; }
public ObjectManager(IObjectDal DAL)
{
ObjectDal = DAL;
}
public List<Object> GetObjects()
{
Worksheet sheet = ObjectDal.GetObjects();
//Business logic to extract each object from the sheet
return new List<object>();
}
}这是我的DAL:
public class ExcelObjectDal : IObjectDal
{
private Workbook book;
public ExcelObjectDal()
{
this.book = Globals.Factory.GetVstoObject(Globals.ThisAddIn.Application.ActiveWorkbook);
}
public Worksheet GetObjects()
{
Worksheet sheet = (Worksheet)Globals.Factory.GetVstoObject(book.Worksheets[name]);
return sheet;
}
}我的问题是,除了我的VSTO之外,我的工作簿不能从任何地方获得。那么,我是否应该只在一个大项目中创建它,而忘记分层,或者我如何从VSTO以外的任何地方访问我的数据(Excel工作表)?
发布于 2019-11-12 00:43:07
问题是VSTO实际上是一个插件框架。在插件框架中使用三层架构会让人感觉很笨拙,这样做需要丢弃大量的框架,并使用自己的框架。
因此,例如,您的DAL不应该返回工作表,相反,您应该使用自己的DTO提取所需的位并将其向上传递。我将传递从UI层调用DAL所需的对象(理想情况下它在IoC容器中,但也可以这样做)。
这将需要编写相当多的代码,但您的业务和UI层将在很大程度上与较低级别解耦。就我个人而言,我想看看您是否可以利用或使用您自己的IoC,可以从VSTO层调用它。它可以将工作簿传递到DAL的构造函数中。
为了将你的经理与excel隔离,这是一项繁重的工作,这可能值得,也可能不值得。这取决于您的业务逻辑的最终复杂性,以及您需要它的可测试性。插件通常不需要与它们所插入的对象隔离...
https://stackoverflow.com/questions/58801171
复制相似问题