问题标签 [service-layer]

我们正在构建一个包含许多层的大型 Web 应用程序。为了与业务层通信，我们使用了一个服务层，Web 层在需要数据时调用该服务层。不幸的是，如果在业务层抛出异常，似乎Web端的服务正在包装异常并重新抛出它们。我们正在寻找一种清晰的方法来封装错误并记录它，而 WCF 不会在原始异常周围包装新异常。

谢谢

我的意思是，假设我的存储库中有一个方法：

如果服务能够以说这个扩展的形式获得额外的数据来表示为客户获取订单：

此扩展最有可能与通用存储库一起使用。

或者您是否应该对每个聚合根有具体的存储库实现，以准确地返回服务所需的内容，仅此而已？

那么，您的存储库是否应该返回 IQueryable？

前几天我问了这个问题：

存储库层是否应该返回数据传输对象 (DTO)？

答案（只有一个人，但我已经预感到这不是一个好主意）是不，存储库以后不应该处理 DTO 对象（它们的目的纯粹是通过线）和服务层应该处理。

现在我想出了一个结构，同时我需要你的意见。这个想法是，当这样做有意义时，存储库层可以返回我定义的接口类型，称为IProjectable. 这包装了查询（存储库层尚未执行查询）但不允许消费者更改查询（它不是IQueryable），只是为了对其执行投影操作（到目前为止仅对我First和ToPagedList）执行投影并实际执行查询。

所以在存储库中是这样的：

在服务层是这样的：

我是否正确地说在这里进行实际数据访问仍然是存储库层的责任（应该是），而对可序列化形式的投影是服务层的责任（应该是）？

我认为有效地做到这一点的唯一另一种方法（User从存储库返回 a并在服务层中Count()对他执行Orders将导致对数据库的额外查询）是定义一个具有所有这些属性的类型并从存储库层，只是不要称它为“Dto”，这看起来很愚蠢，因为它与 DTO 相同，只是为了“纯度”而没有命名相同。这样一来，我似乎也可以大部分时间吃蛋糕了。

我看到的缺点是，您可能会得到一个不匹配的地方，服务层执行的预测实际上无法转换为它不应该担心的 SQL，或者它执行如此复杂的预测，这使得它是什么层是有问题的进行实际的数据访问。

顺便说一句，如果重要的话，我正在使用 Entity Framework 4。

我正在阅读Architecting Microsoft .Net Solutions for the Enterprise，并尝试弄清楚有关 Presenter 和服务层的一些事情。

首先，我的 Presenter 需要调用驻留在服务层中的方法，例如 initialize()、save() 等。但是我在哪里放置对服务层的引用？它应该在 Presenter 的类级别，还是应该在 Presenter 方法本身中定义一个新服务？

其次 - 这在书中也不是很清楚 - 这是从 Presenter 到服务层的处理方式吗？：

大家好，

我已经研究并发现了许多关于设计 MVC 服务层的讨论，但我还没有找到我的确切问题的答案。关于服务层相互依赖性的帖子有一张图片说明了我的想法，但我还有一个问题，我认为引用的帖子中没有涉及到这个问题。

我的应用程序将跟踪在多种情况下与人类交互的非营利组织的数据。也许这个人是客户，也许他们是顾问，或者他们是对手。它们可以是多个。客户后来可能成为对手（想想律师的客户）。

我的想法是，新客户或新对手的创建总是会创建两条记录：一条记录​​在人员表中，一条记录在辅助表中。我在这背后的想法是，将有一个地方（人员表）来检查企业过去是否与给定人员进行过任何交互。

我的问题是，当以 1 到 0..1 的关系表示与控制器层的实体时，(1) 在将类传递给视图之前，控制器是否应该参与组合和拆分类？（2）如果不是，服务层是否应该构建viewmodel？

我在这里阅读了关于 1800 线控制器的帖子。我也读过这篇文章说你的服务层不应该知道视图模型，这让我认为它在控制器层中存在和死亡。如果服务层不接触视图模型，例如， （3）将和对象都返回给控制器是否是好的设计？workerServicePersonWorker

这是我的实体类：

我正在编写一个 ASP.NET MVC 3 应用程序，我发现自己经常在我的操作方法中编写这一行：

（显然与 结合使用AuthorizeAttribute）

还有其他事情经常重复，但这是最突出的，我最终有 3 个操作彼此相邻，每个操作都需要检索授权用户。

所以这需要干燥：

1. 我应该编写一个ApplicationContoller所有其他控制器从中继承并公开一个User属性的方法，还是应该将其添加到我的IAdminService并将其作为方法公开？

2. ApplicationController 在 ASP.NET MVC 中是要避免还是要采用的东西？

我正在使用这种Service Layer --> Repository --> Entity Framework (Code-First) w/POCO objects方法，并且很难更新实体。

我正在使用 AutoMapper 将我的域对象映射到我的视图模型，这对于获取数据很有用，不知道如何将这些更改恢复到数据库中？

使用纯 POCO 对象，我会假设没有任何变化跟踪，所以我看到我唯一的选择是自己处理它。您是否只是确保您的视图模型具有与您的域对象完全相同的属性？如果我只是更改视图模型上的一两个字段怎么办？域对象上的其余字段不会在数据库中被默认值覆盖吗？

话虽如此，最好的方法是什么？

谢谢！

编辑

所以我绊倒的是这个，让我们举一个简单的例子Customer：

1)Controller有一个CustomerService调用 servicesGetCustmoerByID方法的服务。

2)Service调用CustomerRepository并检索Customer对象。

3)Controller使用 AutoMapper 映射Customer到ViewModel.

4)Controller将模型交给View. 一切都很好！

现在在视图中，您对客户进行了一些修改并将其发布回控制器以将更改持久保存到数据库中。

我会假设此时对象已分离。那么模型应该具有与对象完全相同的属性Customer吗？并且您是否必须为您不想显示的每个项目创建隐藏字段，以便它们可以保留回来？

您如何处理将对象保存回数据库？如果您的视图/模型只处理对象上的几个字段会发生什么？

I am integrating Zend Framework and Doctrine 2, and I am discovering the Service layer.

Now I understand (am I wrong ?) that I have 2 architectures possible :

• A model, where classes contain domain logic, i.e. properties + getters/setters + complex methods
• A lightweight model, where classes contain properties + getters/setters and a Service layer, containing domain logic, and modifying the model classes

What are the pros/cons of each ?

It seems weird to me to lose OOP by putting domain logic as external to the model, so I don't understand why use a Service layer.

我有一个 WCF 服务，WCF 服务后面是一个服务层（http://martinfowler.com/eaaCatalog/serviceLayer.html）和存储库层。

因此，客户端调用 WCF 服务层，而 WCF 服务层（充当服务层）调用存储库层。

存储库层返回代表数据库的模型（POCO）。那么我认为我需要将 POCO 转换为 DTO 以通过网络传输的服务层？还是我应该将这些保留为 POCO？

在服务层获得给定对象后，我将其返回给客户端 (ASP.NET MVC)，其控制器负责将从 WCF 服务返回的对象映射到 VIEWMODEL。

我想知道我这样做是对的，即 WCF 服务后面的服务层和存储库层？

控制器负责从 WCF 服务返回的实际模型创建 ViewModel。

另外我想知道是否真的有必要从存储库将返回的真实模型转换为准备好从 WCF 服务返回的 DTO。

我有一个 API（一个 DLL），它有各种返回对象/项目集合的方法。

我想创建一个将项目返回给调用客户端的 Web 服务。

那么最好的方法是什么，在我的 API 上调用方法目录，然后使用 automapper 将它们转换为 DTOS 并将它们返回给 Web 服务？

在内部，我的 API 使用服务/存储库层。

从我的 API 返回的信息并不总是正确的格式。所以我必须做一些调整或编写新的方法。

所以最好的想法是拥有我自己的服务/存储库层，它会为我的 WCF 服务查询数据库目录，而不是使用 API。

或者对我可以使用的大多数项目使用 API，并为 API 不可用的项目实现自己的服务/存储库。

我不想重复我的工作，但我真的看不到选择。

也许服务/存储库应该由我的 WCF 和我的 API 共享？