远程还是不远程？
远程还是不远程？
如果我的术语不是 100% 正确，请原谅我。
在为小公司开发软件（所有 Windows 形式的应用程序）多年之后，我最近从我的岩石下爬出来，发现了远程处理和/或 WCF 的概念。在我过去从事的所有项目中，我们总是让每台客户端计算机直接连接到数据库服务器。最近，在阅读“Microsoft .Net：为企业构建应用程序”之后，我想到通过 WCF 将我们的业务对象公开为 POCO 对象可能更有意义，这样我们的客户端应用程序就不需要安装数据库客户端软件在每台机器上（所有随之而来的东西，就像每台机器的另一个数据库用户许可证）。我们的客户端应用程序只需连接到我们的 WCF 服务，该服务可能会公开“服务层”作为我们业务对象的包装器。
我疯了吗，还是这是分布式应用程序中的常见方法？
更进一步，什么 ORM 解决方案可以指向数据库并创建 DAL 和业务对象，然后可以通过 WCF 公开这些对象？
我也无法完全理解延迟加载在这种情况下如何工作......
谢谢， 乔纳森
To Remote or Not to Remote?
Forgive me if my terminology is not 100% correct.
After developing software (all Windows form apps) for many years for small companies, I recently crawled out from underneath my rock and discovered the concept of Remoting and/or WCF. In all the projects I've worked on in the past, we've always had each of the client machines connect directly to a database server. It's recently occured to me, after reading "Microsoft .Net: Architecting Applications for the Enterprise", that it might make more sense to expose our business objects as POCO objects via WCF, that way our client application would not need the database client software installed on each machine (all that goes with it, like another db user license per machine). Our client app would only have to connect to our WCF service that possible exposes a "Service Layer" as a wrapper around our business objects.
Am I crazy, or is this a common approach in distributed applications?
And further, what ORM solution could be pointed at a database and create a DAL and business objects that can then be exposed via WCF?
I also can't quite wrap my mind around how lazy loading would work in this scenario...
Thanks,
Jonathan
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SOA 正在消亡。使用 MOA（面向消息的架构）的标准 .Net 远程处理是最佳选择！
SOA is deading. Standard .Net Remoting using MOA (Message-Oriented Architecture) is the way to go!
我将把 ORM 问题留给其他人，并且只回答问题中询问这是否是一种常见方法的部分。
这是一种常见的方法，称为 SOA（面向服务的架构）。它有很多优点，但也有很多缺陷。几年前这还很热门，现在仍然很常用，但兴奋程度已经下降。
尽管如此，网络上仍然有大量资源可供研究。最大的问题是要提前思考，因为不同的人对于如何实施 SOA 及其含义有不同的想法。此外，跨平台的承诺在实践中比人们最初希望的更难实现。 （例如，尝试从 Java 调用 .NET Web 服务。这是可以完成的，但是双方都需要做一些工作才能使其正常工作。）因此，如果您需要担心跨平台兼容性，请研究“SOA”跨平台兼容性”，然后再深入探讨。您最好学习如何正确地做到这一点，以免您稍后陷入困境，不得不重新创建一堆最初用于 .NET 客户端但现在需要 Java 客户端的服务（例如，用于智能手机应用程序） ）。
我们自己也犯了这个错误，当我们开始开发 Android/Blackberry 客户端需要使用的服务时，我们最终不得不重新创建大量 Web 服务。鉴于该行业越来越倾向于智能手机开发，现在就开始开发将为您节省以后的大量工作。
I'm going to leave the ORM question for others, and only answer the portion of the question asking if this is a common approach.
It's a common approach, called SOA (Service-Oriented Architecture). It has many advantages, and also pitfalls. It was all the buzz a few years back, and now it's still commonly used, but the excitement level has dropped off.
Still, there are tons of resources on the web to research this. The biggest catch is to think ahead because different people have different ideas of how SOA should be implemented, and what it means. Also, the cross-platform promises are harder to achieve in practice than people originally hoped. (try calling .NET Web services from Java, for example. it can be done, but there is work to be done on both sides to make it work.) SO if you EVER need to worry about cross-platform compatibility, research "SOA Cross-platform compatibility" before getting too deep. You're better off learning how to do that right, lest you be caught with your pants down later and have to re-create a bunch of services originally intended for .NET clients that now need Java clients (for smart phone apps, for example).
We made this mistake ourselves and ended up having to re-create a ton of web services when we started developing services that needed to be consumed by Android/Blackberry clients. Given the way the industry is trending more toward smartphone development, getting it right now will save you lots of work later on.