如何在3层（单层）应用程序中BLL和UI之间传递数据？

发布于 2024-08-13 16:46:32 字数 833 浏览 5 评论 0原文

我是一个相当菜鸟的程序员，正在尝试学习 n 层架构（DAL、BLL、UI）的基础知识。我正在编程的应用程序是用 VB.NET (.Net 3.5) 编写的单层、3 层应用程序。层如下：

DAL

BLL

COMMON - 现在包含 DTO。

我无法确定在 BLL 和 UI 之间传递什么内容。我的直觉告诉我，我应该只将数据传递到 UI，而不是 BLL 中的完整业务对象。考虑两种场景：

1) 将 BO 直接从 BLL 传递到 UI。这暴露了 BO 方法并允许 UI 直接访问 BO，这看起来很糟糕。

2) 仅将相关数据从 BO 传递到 UI。例如，客户有姓名和地址。这些数据确实是我们想要在 UI 中显示/编辑的数据，因此我们只会将该数据返回到 UI，而不是完整的 BO。然后，UI 将调用 BLL 来更新特定的 BO。

我倾向于使用#2，但我不知道实现它的最佳方法。按照我现在的编程方式，如果我只从 BLL 返回数据，则对 BO 的所有引用都将丢失，并且 GC 将声明它们。基于此，我有一些问题：

1）我应该在调用 BLL 之间保持业务对象处于活动状态吗？另一种方法是每次通过 BLL 传递数据时重新创建它们，这似乎是错误的。

2) 在单层架构中保持 BO 存活的最佳方法是什么（如果我们不将引用传递给 UI，如何保存引用？）

3) n 层应用程序如何做到这一点？他们是否让 BO 在 BLL 中保持活动状态并等待来自 UI 的更新？这是否需要在 BLL 中进行大量“簿记”以确保不再需要 BO 时将其释放？

感谢您的任何见解，如果我问了一些愚蠢的问题，请原谅我。我自学了我所知道的一点编程，所以我可能会问一个愚蠢的问题，但我并不知道。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

酒与心事 2024-08-20 16:46:32

请参阅 Pet Shop 作为 3 层架构的示例。我将把 BLL 和 DAL 实现为服务对象，它本身不持有任何状态。由于它们是无状态的，我可以使用 singleton 模式并让 factory 保留它以方便参考。

以下是您可以使用的一些示例 CRUD 方法：

FooInfo DALFactory.FooService.Retrieve(int id);
FooInfo BLLFactory.FooService.Retrieve(int id);

IList<FooInfo> DALFactory.FooService.RetrieveAll;
IList<FooInfo> BLLFactory.FooService.RetrieveAll;

FooInfo DALFactory.FooService.Create(FooInfo entity);
FooInfo BLLFactory.FooService.Create(FooInfo entity);

FooInfo DALFactory.FooService.Edit(FooInfo entity);
FooInfo BLLFactory.FooService.Edit(FooInfo entity);

void DALFactory.FooService.Delete(FooInfo entity);
void BLLFactory.FooService.Delete(FooInfo entity);

正如您在这两种情况下所看到的，您传递的是没有任何逻辑的相同实体对象（也称为数据传输对象）。此架构允许您将 UI 层与 BLL 断开连接，直至丰富的客户端和 Web 服务组合。

Retrieve 和 RetrieveAll 方法的目的是从数据库中获取数据并将其填充到实体对象中。 Create 方法根据给定实体向数据库添加新行。在这个架构中，除了业务逻辑层的BLLFactory.FooService和实体FooInfo对象之外，没有“业务对象”。

就这些对象的生命周期而言，无状态 BLLFactory.FooService 创建一次，只要应用程序处于活动状态，就会重复使用。 FooInfo 可以为每个对象创建一次，然后保留到 ASP.NET 会话或其他内容中。

See Pet Shop as an example of 3 layer architecture. I'll implement both BLL and DAL as service object, which on its own does not hold any states. Since they are stateless, I can use singleton pattern and let a factory hold on to it for easy reference.

Here are some example CRUD methods you could have:

FooInfo DALFactory.FooService.Retrieve(int id);
FooInfo BLLFactory.FooService.Retrieve(int id);

IList<FooInfo> DALFactory.FooService.RetrieveAll;
IList<FooInfo> BLLFactory.FooService.RetrieveAll;

FooInfo DALFactory.FooService.Create(FooInfo entity);
FooInfo BLLFactory.FooService.Create(FooInfo entity);

FooInfo DALFactory.FooService.Edit(FooInfo entity);
FooInfo BLLFactory.FooService.Edit(FooInfo entity);

void DALFactory.FooService.Delete(FooInfo entity);
void BLLFactory.FooService.Delete(FooInfo entity);

As you can see in both cases, you pass the same entity object (aka data transfer object) that has no logic whatsoever. This architecture allows you to disconnect UI layer from BLL down the line to rich client and web services combo.

The intension of the Retrieve and RetrieveAll method is to grab the data from the database and stuff it into entity object. Create method adds a new row to the database based on the given entity. In this architecture, there is no "business object" besides Business Logic Layer's BLLFactory.FooService and the entity FooInfo object.

In terms of the lifetime of these objects, the stateless BLLFactory.FooService is created once, and will be reused as long as the app is alive. FooInfo could be created once per object, and then persisted into the ASP.NET session or something.

回复收藏 0 原文