在我的第一个3层Winform应用程序中，很少有关于BLL和DAL的问题

Question

我正在尝试创建3层winform应用程序。由于这是我第一次尝试3层设计，因此我遇到了问题。

该应用程序将支持附加多个sqlite db文件。

所以我创建了这样的课程

public class Database
{
    public string Name { get; set; }
    public string FilePath { get; set; }
    public bool isAttached { get; private set; }
}

现在我希望收集这些对象。

我应该在下面创建另一个类如DatabaseList，还是足以创建一个List

public class DatabaseList : List<Database>
{
...

VS

List<Database> myDatabases;

应该在Form1.cs中创建什么？

例如，我假设上面的集合应该在BusinessLayer中而不是在Form1.cs中创建，并且只在Form1.cs中创建BusinessLayer类。这是对的吗？

在哪里放置附加方法？

方法是这样的：

    public void AttachDB(Database db)
    {
        MySqliteHelper.Attach(db.Name, db.FilePath);
        this.Add(db);
    }

我是否将该方法放在DatabaseList类中（如果这是创建集合的方式），还是应该在BusinessLayer中？

如何使Attach方法支持其他关系数据库，如MS SQL Compact Edition，它也驻留在一个文件中

我认为使用与MySqliteHelper相同的方法创建另一个通用数据库助手类，而AttachDB方法会调用它。像

这样的东西

MyDBHelper.Attach(db.Name, db.FilePath);

或者Dependency Injections Ninject可能对此有帮助吗？我之前从未使用过，我从Ninject回忆的是一个拥有不同武器的武士，所以在我看来有点类似于我的问题有不同的特定数据库类。

Answer 1

我将部分解决这个问题，因为它涵盖了很多方面。

什么是3层架构？

3层（或 n - 层，分层）架构基本上是任何设计，其中接口不直接与数据库通信，无论多么薄实际的层次是。您可以创建一个具有获取和保存数据的函数的类，它仍然可以作为3层体系结构。话虽这么说，我将在下面解释的可能是3层架构中最常见的实现。

Layer vs. Tier：有什么区别？

要了解3层架构，首先要区分层和层是很重要的。应用程序可以包含许多物理层，但仍然只包含三个逻辑层。如果一张图片确实值一百万字，下面的图表应该为你清楚。

在上图中，业务/中间层由业务逻辑，业务对象和数据访问对象组成。此层的目的是为用户界面和数据库之间的中间人提供服务。

数据访问层（DAL）

数据访问层由数据访问组件（见下文）和一个或多个数据访问对象组成。根据需要，数据访问对象通常以两种方式之一设置：

1. 每个业务对象的数据访问对象
2. 许多 Business Objects共享的数据访问对象

听起来你将要处理几个数据库，所以使用一对一选项可能是有意义的。通过这种方式，您可以灵活地指定哪个数据库/连接与哪个业务对象相对应。



数据访问组件

您的数据访问组件应该是一个非常通用的类，只包含连接数据库和与数据库交互所需的简单方法。在上图中，该组件由dbConnection类表示。

问题＆amp;答案

应该在Form1.cs中创建什么？

前端处理的唯一事情是业务对象和业务逻辑。有时不是黑白分明，但这就是主意。

何处放置附加方法？

将连接字符串传递给数据访问组件，而不是Attach方法。连接字符串可用于连接和/或连接到几乎任何数据库。

如何使Attach方法支持其他关系数据库，如MS SQL Compact Edition，它也驻留在一个文件中？

见上文。

我应该在下面创建另一个类如DatabaseList还是足以创建一个List？

老实说，这取决于您，并不影响3层架构的有效性。您知道您尝试满足的具体要求，如果有意义的话，也要这样做。考虑一下数据访问对象将如何与此类进行交互，因为您需要公开执行查询的方法以及从列表中选择的任何数据库的非查询。 / p>

Answer 2

你缺乏的是思考对象及其责任。

哪个对象负责创建数据库描述的实例？它应该是Form1吗？

OOP告诉您，如果您有这样的疑虑，您可以遵循 Pure Fabrication 原则，只需创建另一个类来对此负责。这很简单。

因此，您可以创建一个类，让我们调用它DatabaseManager，将您的数据库列表加上Attach方法。您可能还希望此管理器成为环境类（在其他类之间共享的相同实例），因此您可以从中构建 Singleton （但这不是必需的）。

DI容器可能可以帮助您组织服务并管理他们的生命，但我建议您在滥用此想法之前先阅读一本好书。 Mark Seemann的“.NET中的依赖注入”很好。

Answer 3

您需要考虑模块化和抽象。看到你有多个实体要跨层传递。

以下是示例： 1.演示文稿将创建业务层或业务外观的对象。但它会期望来自业务层的逻辑实体。

1. 业务层将创建DataAccess的对象，并期望DataAccess的逻辑实体执行业务操作。

2. DataAccess将尽其所能从数据库中获取信息。因此，如果您需要连接oracle / sql / sqllite / files系统，除了它将转换或说初始化逻辑实体（实体是仅包含属性的类）。

因此，每一层都有自己的责任并执行它负责的操作。

所以我认为你的数据库相关操作将进入DataAccess。