Question

过去几天我看过几个Web-API项目样本，以改善我项目的架构。

到目前为止我有什么：
Project.WebApi - 主要由控制器，脚本等组成 Project.DAL - 包含我的模型和存储库类还有更多与之无关的部门。

我的问题是：
1.我看到很少有项目在DAL库中将模型和存储库类放在一起，而其他项目将它们分开。意见问题哪一个更好？
2.我的控制器接收到JObject，因此我发现自己不止一次地将JObject转换为控制器中的数据对象，这对我来说似乎是错误的。我想为我的每个模型创建一个自定义JSON转换类。对于这样的类（以及其他类似的类），创建一个名为Common或core的库是否可以？或许我误解了这个概念？代码示例：

var taskId = (int)taskstatus["Id"];
var status = (string)taskstatus["Status"];
var userCreated = (int)taskstatus["UserCreated"];
if (taskId == 0 || status == null || userCreated == 0)
                return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
var newTask = new Task{
Id = taskId,
userCreated = userCreated
...
}

将上面的所有代码留在控制器中对我来说是错误的，控制器应该更简单，更清洁 3.存储库如下：

public class Context : DbContext
{
public DbSet<Tasks> Tasks { get; set; }
public DbSet<Projects> Projects { get; set; }
...

就这么简单。再次，回到我的控制器 - 我发现自己在我的控制器中做了很多复杂的查询，我觉得这也是错的。我不认为控制器应该处理这些问题。处理复杂查询的最佳做法是什么？也许我应该创建一个继承我的上下文类的新类，覆盖它的一些父类并在那里进行复杂的查询？

Answer 1

我会将它放在同一个项目中，因为这些类与数据库紧密相关（但这也可能取决于你的设计）。
我会将对象转换代码放在您的控制器之外。我建议使用转换库，例如Automapper，或者查找旨在实现此目的的模式。例如：Design pattern for converting one model to another model
我会在存储库中放置复杂的查询。简单的linq查询（例如只包含一个orderby的查询）可以保留在控制器中。

Answer 2

我个人会将你的模型放在单独的项目中。这使得将来可以轻松地与其他项目共享这些项目，而无需使用DAL标记。
同意Joanvo，AutoMapper是要走的路。此外，拥有一个单独的项目，其中包含用于将JObject映射到模型/ poco对象的AutoMapper配置文件，这将是一个明智之举。你希望你的控制器尽可能愚蠢。在web api项目中，我在控制器上的工作几乎总是接受请求，然后将其交给业务层（在您的案例映射层中）。
您不应该在控制器中放置任何查询....这就是您的DAL所针对的。

Web API分层体系结构 - 最佳实践

2 个答案: