.NET 多层设计 LINQ
我对该架构还很陌生，我正在为我的下一个 .NET 项目设计一个应用程序。我提出的架构设计如下：
它是传统的三层应用程序，其中包含： 数据层（LINQ + 部分类） 业务逻辑层（实体+验证逻辑） （可选）服务层（WCF） UI（网站和 Windows 应用程序）
数据层： 数据层将包含我的 DataContext 类（即 LINQ）和部分类。这些部分类将具有基本计算逻辑（例如计算增值税）和其他数据库级验证逻辑。
业务层： 这将具有类似于数据层的条目，但也将包含 UI 级别的验证逻辑。例如，如果用户尝试输入数据库中不存在的用户名，则需要告诉用户该用户不存在。 （这是我苦苦挣扎的地方）。每当调用属性时（而不是创建对象时），该对象都会延迟加载。
用户界面： 这将是一个传统的 UI 层，将在其中调用业务实体。
即使使用 LINQ，我也将业务层与数据层分离的原因是，如果我希望为 WCF 服务添加更多中间层实体，那么我希望它与业务层而不是数据进行对话。我相信当应用程序增长时解耦会有所帮助。（我认为）
如果有人可以对上述几行发表评论，我将不胜感激。我真正的问题是编写商务课程（显然）。例如，在延迟加载中，当我尝试加载对象并且数据库中没有数据时，我希望我的 UI 向用户显示该用户不存在（如果我正在搜索用户名）。您对此有何建议？对此的任何意见都非常受欢迎。
非常感谢， 普雷亚什
I am quite new to the architecture and I am desiging an application for my next .NET project. My proposed architecture design is as follows:
It is traditional three tier application which contains:
DataLayer (LINQ + Partial Classes)
BusinessLogicLayer (Entities + Validation Logic)
(Optional) Service Layer (WCF)
UI (Web site and Windows App)
Data Layer:
The data layer will contains my DataContext classes (i.e. LINQ) and partial classes. These partial classes will have basic calculation logic (for e.g. Calc. VAT) and other database level validation logic.
Business Layer:
This will have entiries similar to Data Layer but also will contain validation logic at UI level. For e.g. if user try to enter username which does not exists in the database it needs to tell user that user does not exists. (this is the place where I am struggling). The object will be Lazy Loaded whenever the properties will be called and not when the Object is created.
UI:
This will be a traditional UI layer where Business entities will be invoked.
The reason why I am saperating the business layer from the DataLayer even when using LINQ is becouse if I wish to add more middle tier entities for e.g. WCF service then I want it to talk to Business Layer rather then Data. I belive decoupling helps when the application grows.(I think)
I would appriciate if someone can comment on above lines. My real problem is writing the business classes (obeviously). For e.g. In Lazy loading when I try to Load the Object and it there is no data in the database then I want my UI to show the user that the user does not exists (if I am searching for username). What are your recommondations with regards to this. Any input to this is much appriciated.
Many thanks,
Preyash
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这里的一条建议是遵循 KISS/YAGNI 范例。不必仅仅因为您认为稍后当您的应用程序增长时会需要它，就一定要深入研究复杂的架构。
也许首先要了解您的应用程序需要做什么，并考虑实现这一目标的最简单方法。您将节省自己的时间，并快速启动并运行原型，这几乎肯定会教会您很多有关问题的知识，然后您可以将其纳入下一个版本或增强功能中。
关于您对用户界面的疑问，这是一个很好的例子，说明保持架构简单可以使其他一切变得简单。您的 UI 可以轻松解释加载用户的简单方法（如果用户不存在则返回 null）。但是，一旦您进入复杂的业务对象，您就需要考虑更多的含义。您的 UI 与复杂的业务对象紧密耦合，而不是与简单的数据访问 CRUD 接口紧密耦合，因此您可能会说您的应用程序耦合性更强，而不是更少。
在为客户端创建应用程序时，我的方法通常是拥有尽可能薄的服务器层。将业务逻辑与数据（即在数据库中）和 UI 逻辑保持在 UI 中（即在客户端中）一起，服务器所做的就是使用 Web 服务在客户端/服务器之间传递非常简单的数据对象。
如果您不喜欢数据库中的逻辑，另一种选择是将逻辑放入服务中。
在这两种情况下，我认为将逻辑放入新的业务实体中是有好处的，因为如果这样做，您将在应用程序中传递逻辑，从而增加耦合，而不是传递数据并保持逻辑私有。
One piece of advice here is to follow the KISS/YAGNI paradigms. Don't necessarily dive in with a complex architecture just because you think you'll need it later when your application grows.
Maybe start with looking at exactly what your application needs to do, and think of the simplest way in which this can be achieved. You will save your self loads of time and get a prototype up and running very quickly which will almost certainly teach you a lot about the problem that you can then factor in to the next version or enhancement.
With regards you question on the user interface, this is a good example of where keeping the architecture simple keeps everything else simple. A simple method to load a user that returns null if the user doesn't exist can easily be interpreted by your UI. But once you get into complex business objects you need to think through a lot more implications. Your UI becomes tightly coupled to the complex business objects rather than a simple data access CRUD interface, so you might say your application has become more coupled rather than less.
My approach when creating applications for clients is generally to have as thin a server layer as possible. Keeping the business logic with the data (i.e. in the database) and the UI logic in the UI (i.e. in the client), all the server does is pass very simple data objects between client/server using web services.
An alternative, if you're not a fan of logic in the database, would be to put the logic in services.
In both cases I think there is merit over putting the logic into new business entities, because if you do this you are passing your logic around the application and so increasing coupling, rather than passing the data and keeping the logic private.