为什么大型网站的后端和前端使用不同的语言?


26

我对小型MVC应用程序的理解是,您拥有处理HTML,JS,jQuery等的前端,而拥有由控制器和模型组成的后端。

但是,当我与大公司的开发人员交谈时,他们经常提到拥有前端层和后端层。所以有时候,我可能会听说他们在C#中有一个前端,在Java中有一个后端。为什么任何公司都希望使用不同语言的后端和前端?这是否有助于大型网站更好地扩展?

当人们说他们的前端是用C#构建的时,这是否意味着他们使用的是前端框架(如.NET)和后端的其他框架(如Spring)?还是意味着完全不同?


6
您为什么要用相同的语言来拥有所有东西?!语言是不同的,所有语言都针对不同的目的进行了调整。没有所谓的“通用语言”。
SK-logic

33
@ SK-logic:您真的不能想到以单一语言编写单个应用程序有什么好处吗?
back2dos

10
@ back2dos,不,我看不到任何优势。太愚蠢了,试图将一种语言用于非设计用途。在另一种语言更适合的区域使用一种语言是很愚蠢的。
SK-logic

25
@ SK-logic:使用该参数,使用任何流行的语言开始都是愚蠢的,因为对于任何领域,都存在专门针对该领域设计的DSL。但是我相信您知道这一点,所以我怀疑您今天只是在一种狂躁的情绪中,否则您将避免这种泛化和情绪爆发的程度。
back2dos

3
团队/经理和平台将在选择任何特定任务之前推动语言选择。选择C#ASP.NET作为Java旧式后端应用程序的Web前端,并不是因为此Web应用程序有“如此独特”之处,以至于将它放在Windows堆栈上是如此完美。
JeffO

Answers:


67

“前端”和“后端”可能是模糊的术语,尤其是在企业应用程序中。“前端”可以表示UI,也可以是整个应用程序。“后端”可以用来表示内部,也可以是消耗的数据库或外部服务。术语的含义通常完全取决于您与谁谈话。因此,您是否可能问过“嘿,那是什么意思?”

当您进入大型企业开发时,您将有很多团队编写大量代码。这些团队将在不同的位置使用不同的范式以不同的语言进行开发。此代码中的某些代码将需要一起工作,而大部分代码则不需要。

我在一家大银行工作。我的团队使用C#开发我们的应用程序。所有的。但是,我们使用的Web服务大部分是用Java编写的,这些服务与其他服务通信,而其他服务则与其他服务通信,这些服务从适当的数据存储中获取帐户数据,以及谁知道这些语言使用什么语言。

简短版:人们使用工具来完成工作。


1
现在,我想制作一个用Malbolge编写的公共Web服务,它做的事情确实非常简单/常见,以便有人可以说他们最远的后端在使用它。
2013年

如何实现这种语言组合效果?
2014年

17

我认为您需要扩大一个问题:为什么大型软件项目使用不止一种编程语言?

有许多可能的答案,最值得注意的是:

  • 大型应用程序由许多相对独立的部分组成;通常,每个部分都是由不同的团队甚至不同的外部承包商构建的。出价最高的好处通常大于以相同语言提供的所有好处。
  • 语言来去去去,有时大型系统的一部分比生态系统更早。微软世界的一个例子是,现在有多少公司在所有新项目中都使用C#,但是它们仍然具有相当多的VB代码库。仅仅为了用最新的编程语言完成项目而重写项目的成本实际上是没有道理的。
  • 与第三方组件的接口。如果您的C#生态系统需要执行仅存在Java解决方案的特定任务,那么您有两种选择:自己实现解决方案,或者使用Java解决方案并开发一些胶水将其集成到您的系统中。对于任何不重要的任务,后者几乎总是便宜。

实际上,性能考量从来都不是原因,除非在诸如高频交易之类的对性能至关重要的应用中,在这些领域中,以具有更好的运行时性能的语言(例如C ++)编写关键的核心引擎可能是有益的,但使用Java或C#等更高级别的支持系统(UI,报告等)。


6

它在大型企业中是相对的。
在我公司里,烟囱大概是

(html/javascript)--> (JSP on Tomcat and Java based WebCMS) -> (.Net SOA)  

因此对于Web开发团队来说,前端是HTML / JS,后端是Java。对于企业而言,前端是Java,后端是.Net。

实际上,.Net层必须与COBOL / UNIX应用程序一起使用以进行开票和索赔,因此从这个角度来看,.Net是前端,而COBOL是后端。

是的,正如其他人提到的那样,我们有UX设计人员,HTML / JS开发人员,Java开发人员,Web中间件,.Net开发人员,SQL开发人员,COBOL开发人员团队在堆栈的每个部分工作。

实际上,在任何足够大的企业中,都是乌龟。


+1龟。我很高兴自己不是前端是汇编语言的乌龟。
kmote

5

令人困惑的语义

这是一个语义问题。当有人说.NET前端或Java前端开发人员时,他们通常是在谈论对模板语言非常了解的人,也许是永远不要再使用的框架(例如用于尝试隐藏网页模板的Webform)。从不希望或至少被假定为不希望了解所有这些废话的应用程序开发人员通过http墙(即“ Web开发”)获取内容。对于.NET和Java混合的情况,我不确定,但是我只能猜测,就MVC而言,他们让Java负责所有业务模型,而.NET处理了所有其他方面,这将更好地描述作为“中间层”,但仍然是所有服务器端。

真正的分离是服务器上发生的事情与客户端或浏览器上发生的事情。您可以轻松地将要发送或代表前端的HTML与“前端开发”混合在一起,因此在讨论我通常的工作时,我更喜欢使用术语客户端和服务器端而不是前端和后端来避免混淆, (通常是客户端工作)。

客户端语言

我们在浏览器上使用相同语言集的原因是因为浏览器位于接收端,并且在大多数情况下(目前,Microsoft和Adobe对此一直存在致命的抵制),没有人愿意发送三个同一客户端的不同版本可以满足每个潜在客户的需求,或者需要安装专有插件才能使Web正常工作。此外,这三种语言实际上很好地封装了客户端的关注点,从而使我们能够通过保持文档结构,外观和行为之间的松散耦合来快速构建和修改Web应用程序前端。您可以更改其中一个而不必很轻易地更改其他两个。

服务器端语言

当然,在服务器端Web上有成千上万个选项的原因是因为您可以。是您的服务器。它所要做的就是通过http / ssl进行通信,其余的一切取决于您。顺便说一下,JavaScript现在是一个选择,但这提出了一个有趣的问题。您是否仍然应该将Web应用程序当做类似HTTP墙上的两个应用程序。我的痛点见解是,是的,应该,我喜欢Node.js。


2

简而言之,在您拥有大型项目的地方,您还拥有多个开发人员团队来从事该项目,而这些团队往往专门研究应用程序的不同层。

如果您专注于Web UI,并且在选择实现时具有灵活性,那么您更有可能使用Web ui目标语言,例如JScript或Flex,而不是C#。

同样,如果您位于应用程序的事务数据存储端,一次要处理许多并发操作,则倾向于使用诸如erlang之类的专用语言。(或部分使用这些语言实现的第三方产品)


2

原因是业务风险平衡。

假设您是一个城市中的大型雇主。您必须雇用许多开发人员来构建许多不同的服务。假设您最初的评估是Lanuage A最适合您的兴趣,并且您想从中开始。

如果您致力于一项技术,则可能会耗尽人才库。当语言B的明星指日可待时,您确定要聘请像样的Langauge A吗?如果明天Langauge A的框架抓住并得到主要开发人员的支持怎么办?如果明天会有令人惊奇的语言C,您会因为五年前致力于语言A而忽略它吗?

理想情况下,您想要的是一个具有不同语言的异构系统,可以反映当前的人才库和技术趋势。您希望这种平衡随着人才库和趋势的变化而缓慢变化,以便您的所有系统在任何时候都可以使用,并且可以雇用人员来维护它们。

...这就是公司所做的事情。


1

将您的前端和后端视为使用相同数据源的单独应用程序会很有帮助。

即使对于较小的站点,您也可以将前端视为客户端与之交互的对象,而将后端视为类似CMS的对象。这些可以轻松地是单独的MVC应用程序。前端仍然需要模型和控制器来运行-毕竟,控制器是站点访问者的切入点,而模型将成为您从数据库向用户获取数据的方式。

我倾向于在后端使用Django / Python作为CMS,在前端使用Rails,CodeIgniter或Spring MVC。通常别无选择。客户已经在前端以某种语言设置了一些旧站点,而他们只需要CMS解决方案。如果不告诉他们,大多数客户甚至都不知道CMS正在运行其他语言或框架。

这实际上是找到最适合您要构建的站点的方法。前端和后端实际上只需要共享数据库,因此只要它们两者都可以使用,就可以随时为当前任务选择最佳选项。


0

后端语言的一个示例是PHP,它是一种脚本语言。当请求一个PHP页面时,服务器读取PHP代码并呈现标记。结果是发送给您的HTML。您,网页查看器,永远不会看到一行PHP代码。假设Web服务器管理员正确完成了他或她的工作,服务器将并且永远不会向您显示实际的PHP代码。当页面被提供并且代码转换的结果是HTML时,将对其进行解析。


您正在将客户端与前端混在一起。在企业应用程序中,后端是存储数据和处理订单(包括更大的业务逻辑)的地方。前端是调用这些后端系统以驱动Web端(使用任何技术),桌面应用程序或移动应用程序的内容。所有这些都被认为是前端编码。接下来是客户端对服务器端,但是我在这里空间不足。
Rob van der Veer

我看不出您的答案如何解决以下主要问题:为什么在前端和后端使用不同的语言。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.