N 层对象参数

Question

我在 n 层概念上苦苦挣扎。起初我有这样的概念，我的域实体将在我的 3 层中共享（DAL、BLL、服务）。但最近被告知这是一个旧概念，并没有真正遵循 SOLID 概念。而是被告知为每一层创建和对象。

Service
  ObjectService
Business
  ObjectBus
DAL
  Object

哪个是Service还是要靠业务，业务要靠dal等等。但是我不确定如何传递我的对象或如何创建它们。

假设在我的数据层我有一个 person.cs 具有以下属性

public class Person:Base
{
    public string firstName { get; set; }
    public string lastName { get; set; }
    public string middleName { get; set; }
}

我应该在我的业务对象中创建这样的业务方法

Boolean CreatePerson(userrole r,string f, string l, string m);

或者我应该这样做

Boolean CreatePerson(PersonHandler pmo);

我有一个 class PersonHandler

public class PersonHandler
{
    public UserRole r { get; set; };
    public Person p { get; set; };
}

在这种情况下，用户角色只是业务层需要的额外属性。我喜欢为业务层创建一个对象，因为我可以更轻松地更改与该对象关联的所有属性，但是我觉得我仍然需要访问域实体 ( Person )，有人告诉我这很糟糕。但如果我为每个对象创建一组属性，我就觉得这是多余的。如果将来我在 DAL 更换我的人怎么办，这是否意味着我必须更改每一个上升阶梯的参数？

这里是我的结构文件夹的 def 中的更多示例

这是我的 DAL 结构。

Answer 1

请注意，Person 类型特定于数据层。业务层（和其他层）不知道 Person 是什么。业务层有自己的想法 "person"，并且应该有一个单独的 class，可能还有您可能需要的任何额外属性。这就是多层的意义所在。

现在，您不能直接跨层移动对象。你需要一个相邻层之间的映射器，它需要一个对象，比如 DataLayer.Person 并将其转换为 BusinessLayer.Person.

您可以构建自己的映射器，或使用 AutoMapper.

之类的工具

Answer 2

你的结构似乎完全矫枉过正。您声明您正在使用 entity Framework。这是一个 ORM，应该将您的业务 entities/objects 映射到数据结构，并且应该这样使用。

为什么不首先使用带有属性的 EF 代码创建域，以将域实体映射回 sql table？我假设后端有 sql。将您的业务逻辑保留在您的领域模型中，否则您可能会冒着创建 anemic model

的风险

对于前端，我将定义代表您呈现给用户的 screen/view 的视图模型，因为它与域对象是分开的。然后从您的域对象填充视图模型。

N 层对象参数

N-tier Object Parameters

c#

asp.net

n-tier-architecture