我对这个架构很陌生，我正在为我的下一个.NET项目设计一个应用程序。我提出的架构设计如下：
传统的三层应用程序包含： DataLayer（LINQ +部分类） BusinessLogicLayer（实体+验证逻辑） （可选）服务层（WCF） UI（网站和Windows应用程序）
数据层： 数据层将包含我的DataContext类（即LINQ）和部分类。这些部分类将具有基本计算逻辑（例如Calc.VIN）和其他数据库级验证逻辑。
业务层： 这将具有类似于数据层的entiries，但也将包含UI级别的验证逻辑。对于例如如果用户尝试输入数据库中不存在的用户名，则需要告诉用户该用户不存在。 （这是我正在努力的地方）。无论何时调用属性，对象都将是Lazy Loaded，而不是在创建Object时。
UI： 这将是一个传统的UI层，其中将调用业务实体。
如果我希望为例如添加更多的中间层实体，即使在使用LINQ时，我也正在从DataLayer中操作业务层。然后我希望WCF服务与Business Layer而不是Data交谈。我相信当应用程序增长时，解耦会有所帮助。（我认为）
如果有人可以对上述内容发表评论，我会赞不绝口。我真正的问题是编写业务类（显然）。对于例如在Lazy加载时，当我尝试加载对象时，数据库中没有数据，那么我希望我的UI向用户显示用户不存在（如果我正在搜索用户名）。您对此有何建议？对此的任何输入都很受欢迎。
非常感谢， Preyash
答案 0 :(得分：2)
这里的一条建议是遵循KISS / YAGNI范式。不一定要考虑复杂的架构，因为您认为在应用程序增长之后您将需要它。
也许首先要确切了解应用程序需要做什么，并考虑实现这一目标的最简单方法。您将节省自己的时间并快速启动和运行原型，这几乎肯定会教会您很多关于您可以考虑下一个版本或增强功能的问题。
关于用户界面的问题，这是一个很好的例子，保持架构简单，让其他一切变得简单。如果用户不存在，加载用户返回null的简单方法可以由UI轻松解释。但是一旦你进入复杂的业务对象，你需要考虑更多的影响。您的UI与复杂的业务对象紧密耦合，而不是简单的数据访问CRUD接口，因此您可能会说您的应用程序变得更加耦合而不是更少。
我为客户端创建应用程序时的方法通常是尽可能减少服务器层。保持业务逻辑与数据（即在数据库中）和UI中的UI逻辑（即在客户端中），所有服务器确实使用web服务在客户端/服务器之间传递非常简单的数据对象。
另一种选择，如果你不是数据库中逻辑的粉丝，那就是把逻辑放在服务中。
在这两种情况下，我认为将逻辑放入新的业务实体是有好处的，因为如果你这样做，你就会在应用程序中传递逻辑，从而增加耦合，而不是传递数据并保持逻辑私有。 / p>