Question

我目前正在为学校做一个CRUD项目，基本上他们希望我们有这种结构（3个项目）：

这基本上意味着我们无法直接从网站访问类库：

Website
       \
        \
         Web Service
                    \
                     \
                      Class Library

现在当然有多种解决方案可供选择，以便在Web服务中提供抽象以分离例如检索文章的方法和检索类别的方法（这是两个不同的entiries并且在类中有两个单独的类libary）：

我可以做一个具有所有方法的Web服务（GetAllArticles，GetAllCategories，GetArticleByID等），网站只引用这一个Web服务。但是，这当然会导致所有方法都在一个类中（即单个Web服务）
或者我可以创建多个Web服务（Articles.asmx，Categories.asmx等...）并从网站引用所有这些服务，然后根据我需要检索的数据调用我需要的服务

但我的意思是对我来说，上面的解决方案并不是很理想，因为如果我有第一个解决方案，我会在一个类中拥有大量的方法（没有任何抽象），在第二个解决方案中，我将不得不从网站上引用10种不同的Web服务（一种用于文章，一种用于类别等）

在学校，他们告诉我们使用Web服务（或Web服务）访问类库，然后使用Webmethods从类库中检索数据，但我之前提到的两种解决方案看起来都有点狡猾。 / p>

有没有更好的方法来实现这种结构？

Answer 1

在您的示例中，您为文章提供了一项服务，为类别提供了一项服务。这当然只是一个例子，但在这种情况下将它们分开是没有意义的，因为拥有使用类别数据和文章数据的查询和/或例程是非常可能和常见的。

考虑到这一点，通常根据它们彼此相关的程度对例程进行分组是最有意义的。如果您可以将所有可能的例程分成三个干净的组，几乎没有重叠，那么有三个服务是有意义的。如果您无法完全分离任何例程，则应将自己限制为一个Web服务。

但是关于你的声明“没有抽象”是一个网络服务的缺点 - 这不一定是真的。您总是可以在 Web服务后面创建抽象层，这样服务类本身就只是一个具有许多精简方法调用的外观，可以在其他地方进入更大的逻辑。

最后，真正重要的唯一方法是因为它是唯一可行的方法：采用最简单的方法，仅构建您需要构建的内容，只需几层尽你所能;只有当你遇到一个无法以更好的方式解决的问题时，才会增加复杂性，而不是增加复杂性。增加复杂性总是比把它带走更容易。

Answer 2

我会把所有webmethod放到同一个类中。 webmethods应该只是你业务类的包装，以及你需要的任何输入验证和授权。

由于Web服务通常由mahcines而非人类使用，因此不需要层次结构。如果为每个业务类创建web方法类，则管理URL和Web服务器会成为负担。

如果您打算使用浏览器自动生成的HTML页面来调用您的Web服务作为主要用户界面，那么您需要小心一点。例如，如果需要验证请求，则无法依赖SOAP头。

Answer 3

为什么不使用ADO.Net数据服务？