架构考虑因素

时间:2009-08-04 07:43:49

标签: architecture

我正在设计一个Web应用程序,我正在考虑在前端使用python-django,在后端使用C#-WCF-Entity Framework。我的核心竞争力是C#,因此选择了后端技术。但是,我不想在前端使用C#,因为我更喜欢django的简洁设计与ASP.NET以及动态语言提供的灵活性。我打算对WCF服务进行REST调用以进行所有数据访问(即我根本不会使用django模型)。

我的问题......:

  • 在可扩展性方面,这是一个很好的架构吗?这个架构是否存在明显的,危及项目的缺点?简单地使用ASP.NET并忘记REST调用会不会更好?

  • 该体系结构也引发了对托管的担忧,因为很难找到也支持.NET的django主机。在Google App Engine上托管前端和在Windows Azure上托管后端是明智之举吗?

您的回复将受到高度赞赏。

感谢。

4 个答案:

答案 0 :(得分:1)

确实,找到允许这样做的主机可能会限制您的选择。

Python / Django,REST等等都是不错的选择。避免使用ASP.NET前端的东西在维护成本,对其他(即更便宜的)前端服务器的可移植性方面听起来确实不错。通过实现您建议的架构,可实现可扩展性。

对于Google AppEngine,您可以选择AppEngine,Java和Google Web工具包。一个非常好的Web应用程序平台,特别是如果您需要丰富的用户体验和可伸缩性是一个严重的问题。除非您使用.NET“锁定”,否则在此设置中选择Azure是没有意义的。

答案 1 :(得分:1)

我建议通过减少您正在使用的技术数量来简化架构。

特别是使用ASP.net MVC作为前端而不是python。

使用WCF在前端和后端之间进行通信。然后使用SOAP或REST只是配置更改。

当您使用REST与后端通信时,您可以选择自己托管或使用Windows Azure。

答案 2 :(得分:0)

一个强大的业务层,以您认为最舒服的语言开发 - 这似乎是一个好主意。

解耦表示层,甚至可能在将来为不同的客户端平台提供多个这样的层 - 也是合理的,我已经在这些线上看到了成功的系统。

RESTful服务似乎在易于开发方面非常有效。我希望在使用文本数据传输机制(任何风格的Web服务)时会有一些性能开销,但仔细设计这通常不是一个不可逾越的问题 - 看看许多Rich UI浏览器应用程序的性能几乎可以肯定使用具有文本有效负载的AJAX调用。

我没有看到这种架构的选择本质上阻碍了可扩展性 - 显然你必须正确地处理业务层,仔细管理状态等,但我不明白为什么这种选择技术会引入扩展问题。

答案 3 :(得分:0)

通常在前端有一个python-django并通过网络调用一些核心服务进行数据检索和分析是一种非常普通的架构。我们几乎将这一切用于我们公司的所有事情。我们不使用.NET,但我认为它不会产生太大的影响。这种方法非常具有可扩展性,因为如果我们的瓶颈是核心 - 我们在那里增加了计算能力,而根本没有触及前端,反之亦然。

由于您无法从外部访问所有核心服务,因此您可以对所接收的数据类型做出相当强烈的假设,并在前端方面承担验证的负担,这非常方便,因为在核心中具有强类型语言,动态数据验证更容易。为了更充分地利用这个收益,我建议你使用一些类型感知协议进行两部分的通信,比如SOAP或Thrift