软件设计与网络服务设计
我即将设计我的Web服务API，我的API的大部分功能基本上与我的Web应用程序非常相似。
现在的问题是，我是否应该创建 1 个单一方法并将其重用于 Web 应用程序和 Web 服务 api？ （这似乎是合乎逻辑的解决方案，但它非常复杂；复制 Web 应用程序使用的方法并将两者分开，即一种用于 Web 应用程序的方法和一种用于 Web 服务的方法要容易得多。
）你们做吗？
1）重用：一种主要方法，并将它们重用于Web应用程序和Web服务应用程序（我喜欢这个，但它很复杂）
- WebAppMethodX --uses--> COMMONFUNCTIONMETHOD_X
- APIMethodX ---使用----> COMMONFUNCTIONMETHOD_X
即 Commonfunctionmethod_x 包含可重用的通用功能集
PRO：更少的代码、更少的维护、更少的错误。
缺点：非常复杂
2) 重复：两种方法，一种用于 Web 应用程序的方法，一种用于 Web 服务的方法。
- WebAppMethodX
- APIMethodX
PRO：简单
缺点：重复=更多代码，更多维护，更多错误！
I'm about to design my Web service API, most of the functions of my API is basically very simular to my web application.
Now the question is, should I create 1 single method and reuse them for both the web application and the web service api? (This seems to be the logical solution, however its very complicated; it's much easier to duplicate the method used by the web application, and keep both separate, ie one method for the web application and one method for the web service.)
How do you guys do it?
1) REUSE: one main method and reuse them for both web application and web service application (I like this but it's complicated)
- WebAppMethodX --uses-->
COMMONFUNCTIONMETHOD_X - APIMethodX ---uses---->
COMMONFUNCTIONMETHOD_X
ie Commonfunctionmethod_x contains reusable set of common features
PRO: less code, less maintenance, less bugs.
CON: very complicated
2) DUPLICATE: two methods, one method for the web application and one method for the web service.
- WebAppMethodX
- APIMethodX
PRO: simple
CON: duplication = more code, more maintenance, more bugs!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的公共 Web 服务 API 的用例很可能与内部应用程序 API 的用例不同。创建一个公共服务项目/层，并从您的 Web 应用程序和面向公众的 Web 服务 API 中使用同一层。为每个 Web 应用程序和 Web 服务创建单独的 http 可调用方法。
归根结底，存在
1) 不同的安全问题。例如，最好（通常需要）提供一个使用您的公共 API 的示例客户端应用程序，以便其他人可以轻松地了解您所提供的内容。该客户端 API 可能需要传递您提供的已去除内部安全逻辑/内容的对象构造。 （请记住，编译后的 C# 也可能是使用 Reflector 的明文！）
2) 不同的需求和约束。例如，对于内部应用程序调用，您有时会强制执行与面向公众的 Web 服务 API 不同的业务规则（通常后者的范围受到更多限制）。
如果您将业务逻辑设计到服务层中，并分别从您的 Web 项目和 Web 服务项目中很好地调用这些类/方法，那么您将获得大量代码重用，而无需尝试通过混合用例使事情变得过于复杂。
Your use case will very likely be different for your public webservice API than for your internal application API. Create a common service project / tier and use that same tier from both your web app and your public-facing webservice API. Create a separate http-invokable method for each of your web app and your webservice.
It comes down to there being
1) different security concerns. For instance, it is nice (often required) to provide a sample client application making use of your public API so that others can easily get up to speed with what you've provided. That client API may need to pass object constructs that you provide them that have been stripped of internal, secure logic/content. (Remember that compiled C# might as well be clear text with Reflector!)
2) different needs and constraints. For instance, for an internal application call you're going to sometimes enforce different business rules vs. your public facing webservice API (often with the latter being much more constrained to scope).
If you design your business logic into your service layer and invoke those classes/methods well from your web project and your webservice project respectively you're going to have a lot of code reuse anyway without trying to overcomplicate things by mixing use cases.
一种方法。否则，当你发现一个错误并修复它，然后忘记在另一个中修复......你会哭。
One method. Otherwise when you find a bug and fix it in one, then forget to in the other... you will cry.
一种方法是在 Web 服务中，让您的 Web 应用程序调用它。
我不明白两者的“一个主要方法”是什么意思。 Web 应用程序没有 main 方法；它们被部署到应用程序服务器。
还有一点需要注意：您应该使用 POCO 接口来编写您的服务。一旦您这样做了，部署就成为您做出的选择。
One method, in the web service, and have your web application call it.
I don't understand what "one main method" for both means. Web applications don't have a main method; they're deployed to an app server.
One other point to note: you should write your service in terms of a POCO interface. Once you do that, deployment becomes a choice you make.
这取决于..
通常情况下，我会把它们分开。通过这种方式，您可以消除两个高级流程之间的相互依赖性。代码重用在流程中很好，但有时您希望能够在同一服务上使用不同的应用程序。
但是，如果两者高度依赖，您将希望重用相同的函数，以便在一处更改它会在另一处更改它。从而避免开发过程中出现更多潜在问题。
It depends..
Normally, I would separate them. This way you remove interdependency between two high level processes. code reuse is good within a process but sometimes you want to be able to use a different app on the same service.
If the two are highly dependant on each other, however, you will want to reuse the same functions so that changing it in one place will change it in another. Thus avoiding more potential issues with the development process.