我对架构还很陌生，我正在为我的下一个 .NET 项目设计一个应用程序。我提出的架构设计如下:
它是传统的三层应用程序，其中包含: DataLayer(LINQ + 部分类) BusinessLogicLayer(实体+验证逻辑) (可选)服务层 (WCF) UI(网站和 Windows 应用程序)
数据层: 数据层将包含我的 DataContext 类(即 LINQ)和部分类。这些部分类将具有基本的计算逻辑(例如计算增值税)和其他数据库级别的验证逻辑。
业务层: 这将具有类似于数据层的条目，但还将包含 UI 级别的验证逻辑。例如如果用户尝试输入数据库中不存在的用户名，则需要告诉用户该用户不存在。 (这是我挣扎的地方)。每当调用属性时，对象将被延迟加载，而不是在创建对象时。
用户界面: 这将是调用业务实体的传统 UI 层。
即使在使用 LINQ 时我也会从 DataLayer 中分离业务层的原因是因为如果我想添加更多的中间层实体，例如WCF 服务然后我希望它与业务层而不是数据交谈。我相信当应用程序增长时，解耦会有所帮助。(我认为)
如果有人可以对以上行发表评论，我会很感激。我真正的问题是编写业务类(显然)。例如在延迟加载中，当我尝试加载对象并且数据库中没有数据时，我希望我的 UI 向用户显示该用户不存在(如果我正在搜索用户名)。您对此有何建议？对此的任何输入都非常有用。
非常感谢， 猎鹰
最佳答案
此处的一条建议是遵循 KISS/YAGNI 范例。不必仅仅因为您认为以后应用程序增长时会需要它而投入到复杂的架构中。
也许首先要确切地了解您的应用程序需要做什么，然后想出实现这一目标的最简单方法。您将节省自己的大量时间并快速启动和运行原型(prototype)，这几乎肯定会教会您很多有关问题的知识，然后您可以将其考虑到下一个版本或增强功能中。
关于您在用户界面上提出的问题，这是一个很好的例子，说明保持架构简单可以使其他一切都简单。加载用户的简单方法在用户不存在时返回 null 可以很容易地被您的 UI 解释。但是一旦涉及到复杂的业务对象，您就需要考虑更多的含义。您的 UI 变得与复杂的业务对象紧密耦合，而不是简单的数据访问 CRUD 界面，因此您可能会说您的应用程序耦合度更高而不是更低。
我在为客户端创建应用程序时通常采用尽可能薄的服务器层。将业务逻辑与数据(即在数据库中)和 UI 逻辑保持在 UI 中(即在客户端中)，服务器所做的就是使用 Web 服务在客户端/服务器之间传递非常简单的数据对象。
如果您不喜欢数据库中的逻辑，另一种方法是将逻辑放在服务中。
在这两种情况下，我认为将逻辑放入新的业务实体中是有好处的，因为如果你这样做，你将在应用程序周围传递你的逻辑并因此增加耦合，而不是传递数据并保持逻辑私有(private)。
关于.NET 多层设计 LINQ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3519836/