【问题标题】:Build enterprise application without service layer构建没有服务层的企业应用程序
【发布时间】:2011-08-02 10:15:10
【问题描述】:

有很多教程教我们直接使用数据库,例如一些 ORM,但在现实生活中,我不记得有一个大项目直接使用数据库而不是服务,所以教程的数量似乎很奇怪对我来说。
直接连接的应用程序在数据库和应用程序之间的数据传输速度方面具有真正的优势,并且它们没有因服务层而出现的功能限制(例如,让我们采用实体框架和 WCF 数据服务(它本身使用相同的实体数据模型) ))。另一方面,服务解决方案更加安全和灵活,这就是为什么我(我认为许多其他程序员)通常选择它来构建具有某种通用业务逻辑的大型应用程序......但是!有时速度损失高达10倍!真是可悲,应用程序的响应速度不如预期。
所以我想问的问题是:你能分享你自己构建企业应用程序的经验吗?没有 web/services 层?什么时候是一个好的选择?

【问题讨论】:

    标签: c# wcf entity-framework architecture n-tier-architecture


    【解决方案1】:

    企业应用程序!= n 层应用程序。这意味着您可以编写企业应用程序而无需创建单独的物理中间层(业务逻辑)。创建单独的中间层必须始终是需求的一部分,因为它会带来很多额外的复杂性 = 很多额外的成本。

    单独中间层的通常要求是:

    1. 安全性 - 有时 Web 服务器位于 DMZ 中,而中间层必须位于安全网络中
    2. 可重用性 - 您希望在多个应用程序中使用中间层,这也会导致 SOA 需求
    3. 可扩展性 - 中间层可能要复杂得多,因此在前端层上独立扩展它会很有用。如果您想在多个应用程序中使用中间层,您还必须能够独立扩展它。可扩展性要求通常基于性能和可用性要求。

    如果您没有任何此类要求,您可以制作多层应用程序,其中前端和业务逻辑位于同一服务器上的同一进程中。

    【讨论】:

    • 非常好的答案。我通常不希望跨多个应用程序使用相同的业务层。但是安全..这是一个问题。客户端通常具有带有数据库的封闭服务器,并且客户端计算机必须在 VPN 中才能直接访问它。通过服务,我们可以将一台服务器放入 VPN,并通过“开放”网络使用客户端计算机访问它。安全性总是会影响速度。嗯..客户想要更多的响应能力!好的..我会尝试为此类解决方案寻求合理的条件(例如服务服务器和数据库一之间的良好通道以及与所有客户端一起工作的良好服务服务器)
    • 但这不是一个好的解决方案:保护自己免受客户变化和未来需求的影响——构建 n 层应用程序(肯定需要更多时间)?几乎总是客户想要继续一些项目并添加一些功能 - 这可能导致将 2 层更改为 3 层或更多。似乎灵活性几乎总是一个好主意。
    • @nihi:这取决于您的开发方法和与客户的实际经验。灵活性是一个好主意,但同时您不应该开发客户目前不想要的东西(敏捷学校),因为同时您稍后会发现它是浪费的,因为没有进一步的更改需要 3 层应用程序。
    猜你喜欢
    • 2011-05-05
    • 1970-01-01
    • 2014-03-01
    • 2017-06-12
    • 1970-01-01
    • 2019-12-04
    • 2012-05-14
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多