使用 Windows 和 Web 界面编写企业应用程序的最佳方法是什么？
我正在研究一个大型企业应用程序的体系结构，该应用程序将基于最新的 .NET 和 SQL Server 技术。该应用程序将供公众、会员、员工和经理使用。
过去，我们使用 RemoteApp / RemoteDesktop 与服务器上运行的本地 Windows 窗体应用程序进行通信。简单，但笨重。
- 应用程序的某些方面需要以 Web 应用程序的形式呈现。
- 应用程序的某些方面需要以 Windows 窗体应用程序的形式呈现。
Windows 应用程序需要分发给不同地理位置的受众（分公司经理和员工）。
以下是 Windows 界面的目标：
- “瘦客户端”，其行为类似于 Web 浏览器（仅用户界面），
- 在服务器上完成的所有处理都
- 使用与 Web 应用程序相同的代码库 -只是不同的 UI
- 直接开发（易于维护和扩展）
最好的方法是什么？
（我花了相当多的时间研究 .NET Remoting，然后是 WCF，但我没有清晰的经验，希望你能带来。）
谢谢！
I am working on the architecture of a large enterprise application which will be based on the latest .NET and SQL Server technologies. This application will be used by the general public, members, employees, and managers.
In the past, we have used RemoteApp / RemoteDesktop to talk to a local Windows Forms application running on the server. Simple, but clunky.
- Certain aspects of the application need to be presented as a Web Application.
- Certain aspects of the application need to be presented as a Windows Forms application.
The windows application needs to be distributed to a geographically disparate audience (branch managers and employees).
Here are the objectives of the windows interface:
- a "thin client", where it behaves similar to a web browser (user interface only)
- all of the processing to be done on the server
- utilize the same codebase that the web-app does -- just different UI
- Straightforward to develop (easy to maintain and grow)
What are some of the best approaches to this?
(I have spent a fair amount of time looking at .NET Remoting and then WCF, but I don't have the clairty of experience, which I hope you can bring.)
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我正在工作的应用程序具有 Web 界面和 WCF 服务接口。另一个应用程序（WinForms 应用程序）使用 WCF 服务来提供与 Web 应用程序相同的功能，但仅在 WinForms 应用程序正在执行的上下文中进行。它的好处是实际功能位于业务层，Web 应用程序和 WCF 服务都只是呈现不同的 UI 和界面。访问方法。
根据您的描述，类似的东西会起作用。真正的关键是确保 ASPX 页面中嵌入尽可能少的业务逻辑。无论如何，您都必须为其 WCF 端重新创建。
因此，您想要创建一组可以执行应用程序实际功能的业务逻辑类。然后，您的网页包含表示逻辑。如果您按照这种方式进行设置，那么创建向调用程序公开相同业务逻辑的 WCF 服务就相当简单了。这部分是整个事情的真正关键。您只希望逻辑位于一处，因此更改它会同时为两种类型的调用者更改它。
如果您使用 Web 服务 WCF 绑定之一，则可以将服务文件粘贴到 Web 应用程序中并将它们托管在一起。如果您使用诸如活动目录身份验证之类的功能，您将能够同时将其用于两种类型的访问（因为这是一项内部 WCF 服务，而不是面向 Internet 公众的服务，因此可以正常工作）。
我首先从它的 Web 应用程序方面开始，一旦它完成了您想要的操作，您就可以随后添加 WCF 服务，以使项目保持在可管理的规模。
至于 WCF 与远程处理，在这种情况下我更倾向于 WCF。它与网络应用程序非常匹配。
编辑：
1) 接口 - 无论如何，您都需要 .svc 文件中的类来实现服务调用。某些类型的服务（basicHTTPBinding，基于 SOAP）需要接口作为服务契约，但其他类型的服务则不需要（webHTTPBinding，基于 REST）。无论如何，我可能会编写一个接口，它可以让您在不更改服务契约的情况下更改服务实现，这对于客户端来说需要保持一致。
2) 当然可以从 Web 应用程序调用该服务，但这会给 Web 应用程序添加额外的工作层。对于 HTTP 服务，这还意味着您的服务将 XML 序列化所有内容，然后您的 Web 应用程序将需要立即对其进行反序列化。 XML 序列化会对性能造成显着影响。我会避免使用这种方法，因为 Web 应用程序可以更有效地对业务层返回的业务对象进行数据绑定（并且 WCF 会自动为服务客户端进行 XML 序列化）。如果您的网络应用程序需要调用不同应用程序中的另一个服务，那是一回事，但在这种情况下，这不是可行的方法。
3）如果它是面向公众的，那么您对其进行身份验证的方式就会发生变化。对于内部内容，您可以让 IIS 使用 Active Directory 处理身份验证。如果您有 Internet 客户端，它们可能不在 Active Directory 中，您需要使用其他方法。 （HTTP Basic 和 Digest auth 应该还可以，或者您可以执行一些操作，例如将用户名/密码作为参数添加到需要身份验证的方法中。请务必在服务上使用 SSL！）
I have an application at work that features a web interface, and a WCF service interface. Another application (a WinForms one) uses the WCF service to provide the same functionality that the web app provides, only in the context of what the WinForms app is doing. The nice thing about it is that the actual functionality is in a business layer, and both the Web app and the WCF service are simply presenting a different UI & method of access.
From what you're describing, something similar would work. The real key is to make sure that as little business logic as possible is embedded in ASPX pages. Any that is, you will have to re-create for the WCF side of it.
So you want to create a set of business logic classes that can perform the actual functions of the application. Your web pages then contain presentation logic. If you set it up that way, it's fairly straightforward to create a WCF service that exposes the same business logic to calling programs. This part is the real key to the whole thing. You only want the logic in one place, so that changing it will change it for both types of callers at once.
If you're using one of the web service WCF bindings, you'll be able to stick the service file inside your web app and host them together. If you're using things like active directory authentication, you'll be able to leverage that for both types of access at the same time (since this is an internal WCF service instead of an Internet public facing one, that will work fine).
I'd start with the web app side of it first, and once it does what you want you can add the WCF service afterward to keep the project to a manageable scale.
As for WCF vs remoting, in this case I'd favor WCF. It pairs REALLY well with web apps.
edit:
1) Interface - You'll need a class in a .svc file to implement the service calls no matter what. An interface is required as the service contract for some types of services (basicHTTPBinding, which is SOAP based), but not for others (webHTTPBinding, which is REST based). I'd probably write an interface anyway though, it lets you change the service implementation without changing the service contract, which is what needs to stay consistent for clients.
2) It's certainly possible to call the service from the web app, but it's going to add an extra layer of work to the web app. For the HTTP services it also means that your service will XML serialize everything, then your web app will need to deserialize it immediately. XML serialization carries a significant performance hit. I'd avoid this method, as the web app can databind to the business objects being returned by the business layer a LOT more effeciently (and WCF will XML serialize it for clients of the service automatically). It'd be one thing if your web app needed to call another service in a different app, but in this case it's not the way to go.
3) If it's public facing, how you authenticate it changes. For internal stuff you can let IIS handle the authentication using Active Directory. If you've got Internet clients, they're probably not in Active Directory and you'll need to use some other method. (HTTP Basic and Digest auth should still be alright, or you can do something like add the username/password as parameters to methods that need authentication. Be sure to use SSL on the service!)