I'm glad to see that you have some real-world experience in building enterprise architectures and understand the consequences of different architecture. I've seen to many consultants that had just read a book about some new fashionable technology...
Option 1 is certainly the most pragmatic and the most affordable. You'd build an application that is needed now and don't invest into services that might or might not be used in the future. But as I understand it from your descriptions, this could be difficult to sell to the customer.
If you have to go with a distributed architecture (option 2 or 3), I'd still try to put as much as possible on the portal server. To this end, the term business logic has to be defined in a very narrow way. Everything that is even remotely related to the presentation (user settings, structuring of data for presentation purposes, already produced reports etc.) is declared presentation logic so it can be implemented on the portal server. So even if you cannot avoid the duplication and complexity that come with remoting, you can limit it to fewer areas. (Depending on the problem at hand, you could end up with a database on the portal server and a database on the business logic server that were better merged into one because there are so many data references between them. Hopefully, this is not the case here.)
Writing a reusable service with just a single application in mind is a wasted investment according to my experience. The servcie interface will become more complicated for this single application, part of the interface will never be used and hardly tested (because it was built for some imagined future application) and when the second application finally arrives one realizes that it has rather different requirements than foreseen. So the service will need to be redesigned and the already existing application to be modified. So don't start building services unless you have at least two (better three) applications that exist or in the process of being implemented. It pays off in terms of money and qualitiy of the service interface.
This advice isn't very specific but so is your description of the application's business requirements. You probably cannot give more information due to a confidentiality agreement you have signed. But I often found that business requirements help to argue for or against an option. E.g. the requirements, the related data, the data ownership and the involved processes can possibly better delimit the systems then technical considerations.
I'd go with option one, marking carefully services that create interface to the business layer and forbidding to call anything behind this interface from the presentation layer. This enables you to make the switch to the options with remoting (regardless if you choose number two or three) later with reasonably low and predictable cost.
If this is not possible, the option two promises more effective use of resources.
One fun part when dividing presentation an business logic was not mentioned yet - this is when you have to filter data coming from business logic based on data existing only in presentation layer, e.g. user and his/her permission. :)
发布评论
评论（2）
我很高兴看到您在构建企业架构方面拥有一些实际经验并了解不同架构的后果。我见过很多刚刚读过一本关于一些新的时尚技术的书的顾问......
选项1无疑是最务实和最实惠的。您将构建一个现在需要的应用程序，而不是投资于将来可能会或可能不会使用的服务。但据我从你的描述中了解到，这可能很难卖给客户。
如果您必须采用分布式架构（选项 2 或 3），我仍然会尝试将尽可能多的内容放在门户服务器上。为此，必须以非常狭窄的方式定义术语业务逻辑。甚至与演示远程相关的所有内容（用户设置、用于演示目的的数据结构、已生成的报告等）都被声明为演示逻辑，以便可以在门户服务器上实现。因此，即使您无法避免远程处理带来的重复和复杂性，您也可以将其限制在更少的区域。 （根据当前的问题，您最终可能会得到门户服务器上的数据库和业务逻辑服务器上的数据库，这两个数据库最好合并为一个，因为它们之间存在如此多的数据引用。希望情况并非如此 根据我的经验，
只考虑单个应用程序来编写可重用的服务是一种浪费的投资。对于这个单一应用程序来说，servcie 接口将变得更加复杂，部分接口将永远不会被使用并且几乎无法测试（因为它是为某些想象的未来应用程序构建的），并且当第二个应用程序最终到达时，人们意识到它的需求与预见到的。因此，需要重新设计服务并修改现有的应用程序。因此，除非您有至少两个（最好是三个）应用程序已存在或正在实施过程中，否则不要开始构建服务。它在金钱和服务界面的质量方面得到了回报。
该建议不是很具体，但您对应用程序业务需求的描述也很具体。由于您签署了保密协议，您可能无法提供更多信息。但我经常发现业务需求有助于争论或反对某个选项。例如，需求、相关数据、数据所有权和所涉及的流程可能比技术考虑因素更好地界定系统。
I'm glad to see that you have some real-world experience in building enterprise architectures and understand the consequences of different architecture. I've seen to many consultants that had just read a book about some new fashionable technology...
Option 1 is certainly the most pragmatic and the most affordable. You'd build an application that is needed now and don't invest into services that might or might not be used in the future. But as I understand it from your descriptions, this could be difficult to sell to the customer.
If you have to go with a distributed architecture (option 2 or 3), I'd still try to put as much as possible on the portal server. To this end, the term business logic has to be defined in a very narrow way. Everything that is even remotely related to the presentation (user settings, structuring of data for presentation purposes, already produced reports etc.) is declared presentation logic so it can be implemented on the portal server. So even if you cannot avoid the duplication and complexity that come with remoting, you can limit it to fewer areas. (Depending on the problem at hand, you could end up with a database on the portal server and a database on the business logic server that were better merged into one because there are so many data references between them. Hopefully, this is not the case here.)
Writing a reusable service with just a single application in mind is a wasted investment according to my experience. The servcie interface will become more complicated for this single application, part of the interface will never be used and hardly tested (because it was built for some imagined future application) and when the second application finally arrives one realizes that it has rather different requirements than foreseen. So the service will need to be redesigned and the already existing application to be modified. So don't start building services unless you have at least two (better three) applications that exist or in the process of being implemented. It pays off in terms of money and qualitiy of the service interface.
This advice isn't very specific but so is your description of the application's business requirements. You probably cannot give more information due to a confidentiality agreement you have signed. But I often found that business requirements help to argue for or against an option. E.g. the requirements, the related data, the data ownership and the involved processes can possibly better delimit the systems then technical considerations.
我会选择第一个选项，仔细标记创建业务层接口的服务，并禁止从表示层调用该接口后面的任何内容。这使您能够稍后以相当低且可预测的成本切换到远程处理选项（无论您选择第二个还是第三个）。
如果这是不可能的，选项二承诺更有效地利用资源。
尚未提及将表示层与业务逻辑分开时的一个有趣部分 - 这是当您必须根据仅存在于表示层中的数据（例如用户及其权限）过滤来自业务逻辑的数据时。 :)
I'd go with option one, marking carefully services that create interface to the business layer and forbidding to call anything behind this interface from the presentation layer. This enables you to make the switch to the options with remoting (regardless if you choose number two or three) later with reasonably low and predictable cost.
If this is not possible, the option two promises more effective use of resources.
One fun part when dividing presentation an business logic was not mentioned yet - this is when you have to filter data coming from business logic based on data existing only in presentation layer, e.g. user and his/her permission. :)