设计模式问题

时间:2011-03-31 15:58:51

标签: design-patterns

我对设计模式完全陌生......以下是我正在关注的架构。任何人都可以告诉我它的优点和缺点......

  • 实体 - >由具有get / set方法的属性组成
  • DAL - >数据访问层 - >处理数据库执行
  • BLL->业务逻辑层
  • UI - >用户界面

假设我们有一个包含customeridcustomername

的客户表

因此,实体将获得customeridcustomername

的设置属性
  • UI - >将customeridcustomername传递给BLL
  • BLL->做验证将其传递给DAL
  • DAL - >将它推送到数据库

我真的不明白有这么多层......

3 个答案:

答案 0 :(得分:1)

您提到的主题并未真正定义设计模式。毫无疑问,他们是解决方案的一部分。

设计模式是解决软件设计中常见问题的一般可重用解决方案。

在您最终开始编写满足以下某些条件的项目的编码之前,很难概念化为什么设计模式值得付出努力:

  • 适度复杂的应用程序
  • 涉及多个程序员
  • 测试在实施过程中非常重要
  • 您的应用程序的可扩展性在未来很重要(对于需要扩展的程度有未知限制)
  • 同样适用于应用的灵活性

您还可以查看上面的列表,这是程序员在某些情况下选择设计模式的众多原因之一。重要的是要认识到模式很酷并且通常看起来很棒的解决方案,你应该权衡一下你的特定项目是否需要它。否则你很容易受到 Pattern Mania 的折磨。

= d

答案 1 :(得分:1)

一本关于设计模式的好书是O'Reilly的“Head First Design Patterns”。它帮了我很大的忙。它向您展示了良好的设计和关注点分离如何使维护和重用更容易。拥有多个层次的一个方面是,它需要预先进行更多的规划,但最终还是要弥补它。

答案 2 :(得分:1)

您描述的每个图层都有一个单独的角色:

  • UI呈现给用户并允许用户交互
  • BLL验证用户输入&数据健全
  • DAL为数据库提供了一致/连贯的接口

从界面中分离数据验证有许多优点 - 例如安全性,或者(根本)改变用户界面而不改变应用程序核心的可能性。这是模型 - 视图 - 控制器设计模式的基本前提之一。

从业务逻辑中分离数据库访问允许您在不改变业务逻辑的情况下更改数据库实现,数据库架构等,从而将两者分离,

功能上的去耦合应用程序的不同部分允许您独立地测试这些部件,(相对)独立地维护它们等。从长远来看,它可以避免维护头疼,并且通常是错误。