3

我对架构非常陌生，我正在为我的下一个 .NET 项目设计一个应用程序。我提出的架构设计如下：

它是传统的三层应用程序，其中包含： DataLayer (LINQ + Partial Classes) BusinessLogicLayer (Entities + Validation Logic) (Optional) Service Layer (WCF) UI (Web site and Windows App)

数据层：数据层将包含我的 DataContext 类（即 LINQ）和部分类。这些部分类将具有基本的计算逻辑（例如 Calc. VAT）和其他数据库级别的验证逻辑。

业务层：这将具有类似于数据层的实体，但也将包含 UI 级别的验证逻辑。例如，如果用户尝试输入数据库中不存在的用户名，则需要告诉用户该用户不存在。（这是我苦苦挣扎的地方）。每当调用属性而不是创建对象时，都会延迟加载对象。

UI：这将是一个传统的 UI 层，将在其中调用业务实体。

即使在使用 LINQ 时，我也将业务层从 DataLayer 中分离出来的原因是，如果我希望为例如 WCF 服务添加更多中间层实体，那么我希望它与业务层而不是数据交谈。我相信当应用程序增长时，解耦会有所帮助。（我认为）

如果有人可以对上述内容发表评论，我会很高兴。我真正的问题是编写业务课程（显然）。例如，在延迟加载中，当我尝试加载对象并且数据库中没有数据时，我希望我的 UI 向用户显示该用户不存在（如果我正在搜索用户名）。您对此有何建议。对此的任何输入都非常受欢迎。

非常感谢， Preyash

4

1 回答 1

2

这里的一条建议是遵循 KISS/YAGNI 范例。不必仅仅因为您认为稍后在应用程序增长时会需要它而深入研究复杂的体系结构。

也许从查看您的应用程序需要做什么开始，并考虑可以实现这一点的最简单方法。您将节省大量时间，并快速启动并运行原型，这几乎肯定会教会您很多关于问题的知识，然后您可以将这些问题纳入下一个版本或增强功能。

关于用户界面上的问题，这是一个很好的例子，说明保持架构简单可以保持其他一切简单。您的 UI 可以轻松地解释加载用户的简单方法，如果用户不存在则返回 null。但是，一旦您进入复杂的业务对象，您就需要考虑更多的含义。您的 UI 变得与复杂的业务对象紧密耦合，而不是简单的数据访问 CRUD 接口，因此您可能会说您的应用程序变得更加耦合而不是更少。

在为客户端创建应用程序时，我的方法通常是使服务器层尽可能薄。保持业务逻辑与数据（即在数据库中）和 UI 逻辑在 UI 中（即在客户端中），服务器所做的只是使用 Web 服务在客户端/服务器之间传递非常简单的数据对象。

如果您不喜欢数据库中的逻辑，另一种选择是将逻辑放入服务中。

在这两种情况下，我认为将逻辑放入新的业务实体中是有好处的，因为如果这样做，您将在应用程序周围传递逻辑并因此增加耦合，而不是传递数据并保持逻辑私有。

于 2010-08-19T08:13:35.203 回答