2

我正在尝试创建 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>
{
...

对比

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 中回忆起的只是一个拥有不同武器的武士，所以在我看来，这与我的问题有点相似，有不同的特定数据库类。

4

3 回答 3

4

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

什么是 3 层架构？

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

层与层：有什么区别？

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

在此处输入图像描述

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

数据访问层 (DAL)

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

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

听起来您将要处理多个数据库，因此使用一对一选项可能很有意义。这样做，您将可以灵活地指定哪个数据库/连接对应于哪个业务对象。

在此处输入图像描述

数据访问组件

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

问题和答案

Form1.cs 中应该创建什么？

前端处理的唯一事情是业务对象和业务逻辑。有时它不是那么非黑即白，但这就是想法。

在哪里放置附加方法？

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

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

看上面。

我应该在下面创建另一个像 DatabaseList 这样的类还是仅仅创建一个列表就足够了？

老实说，这取决于您，并且不会影响 3 层架构的有效性。您知道要满足的特定要求，因此如果有意义就这样做。不过，请考虑您的数据访问对象将如何与此类交互，因为您需要公开在从列表中选择的任何数据库上执行查询和非查询的方法。

于 2012-05-04T19:04:54.897 回答
2

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

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

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

所以你可以创建一个类，调用它DatabaseManager，把你的数据库列表和Attach方法放在那里。您可能还希望此管理器成为环境类（与其他类共享的同一实例），以便您可以从中构建单例（但这不是必需的）。

DI 容器可能可以帮助您组织服务并管理它们的生命周期，但我建议您在误用这个想法之前先从一本好书开始。Mark Seemann 的“.NET 中的依赖注入”很好。

于 2012-05-02T11:56:40.240 回答
1

You need to think in terms of modularity and abstraction. See you have multiple entities to be passed across layers.

Following are the examples: 1. Presentation will create an object of business layer or business facade. But it will expect the logical entity from business layer.

  1. Business layer will create the object of DataAccess and will expect the logical entity from DataAccess to perform business operations.

  2. DataAccess will do whatever it would like to do to get the information from database. So if you need to connect the oracle / sql /sqllite / files system whatever but it will convert or say initialize the Logical entity (entity is a Class only consisting of properties).

So every layer will have their own responsibility and perform the operation it is responsible for.

So I think your db related operations will go in DataAccess.

于 2012-05-04T17:53:46.867 回答