将数据访问层作为服务层

时间:2017-03-06 21:22:35

标签: architecture backend data-access-layer eve

我对我正在使用的架构有疑问。

我们有一个后端restful服务,一个数据层(由python eve实现,也是一个restful服务)和数据库。数据(访问)层本身是一个独立的restful api。

在我们的后端服务应用程序中,我们有一个定制的python eve存储库,它可以调用数据(访问)层,然后数据层将查询来自数据库的调用所要求的任何内容。

将其分开的原因之一是,我们希望将数据逻辑(查询逻辑)与业务逻辑(后端服务)隔离开来。

成本显而易见,另一层,每个查询的另一轮I / O.

任何有建筑经验的人都可以告诉我,这个独立的数据访问层是不是一个好的做法,为什么?

2 个答案:

答案 0 :(得分:5)

看看你正在讨论的架构,你的项目必须足够大,以证明它的开发成本。对于小型项目,这种架构将是过度的。

假设您的项目足够大,是的;分离DAL,BLL和Application层总是好的。请参阅thisthis

如果您控制每个部件并降低维护成本,那么优势就是清洁分离,从而提高了理解力。

另一方面,正如您所说,成本是显而易见的(另一层,另一轮I / O)。是;这就是我的第一段讨论项目规模的原因。在大型项目中,这是一种权衡;你选择的是其他人。

在大型项目中,主要目标应该是IMO的可维护性。理解premature optimization is the root of all evil。因此,您从良好的可维护架构开始。每种技术都建议了提高性能的基本规则;最初实施它们。如果您发现任何性能问题,请查找并修复它。事实上,由于分层,很容易找到瓶颈。

还有其他好处。您可以单独对每个图层进行单元测试您可以独立处理每一层,例如提高性能,改变技术等。调试过于简单。

答案 1 :(得分:0)

从根本上设计微服务体系结构对大型项目是有利的,否则将浪费资源。但是您需要在创建单独的微服务之前考虑一些事情,因为存在复杂性,例如IPC的开销时间,分布式数据,分发不是免费的,更改数据不再容易,因为它需要跨微服务的不同服务进行协调(在您的案例数据访问层)。由于IPC的数量太多,可能会导致大量的开销时间。因此,需要对API进行设计,使其不会显着增加开销时间。数据跨服务分布,因此需要妥善处理。

是的,这是一个好习惯,原因很简单,您正在进行服务抽象。这样做可以在这些服务松散耦合时独立开发。即使数据库需求发生了变化,其他服务也不必为此而烦恼。意思是说,即使整个项目从MySQL迁移到Cassandra或Hadoop,仅需要更改DAA(数据访问安排层),其余的其他服务都将保持不变。而且调试和测试这些服务也容易得多。

因此,在选择微服务架构(一个具有多个服务以分离业务和数据逻辑的微服务架构)或单片架构(一个包含所有逻辑的服务)时,总​​会有一个权衡。因此,基本上,如果项目很大并且您正在使用整体式体系结构,那么它可能会导致您陷入整体式地狱。随着应用程序变得像泥泞的大球一样巨大,因此,无法快速,频繁和可靠地交付,并且技术堆栈变得越来越陈旧,并且重写也不可行。