具有Web服务的.net应用程序的体系结构

Question

我只需要一些帮助来组织我的代码。这不是哲学，而是真正的问题。我正在寻找一个有效的解决方案。例如在php和symfony框架中，很清楚如何组织代码。在c＃.net中，我感到迷茫 我只是想从头开始重写我的项目重用一些部分。

描述
首先，因为我的目标是许多平台windows mobile，windows desktop，android，web，我似乎应该将功能公开为Web服务，而不是直接与数据库通信。这是对的吗？ 那我需要一些客户端应用程序。一个wpf one，android和windows mobile。

在wpf我想我可以使用MVVM模式。

问题
我使用带有ADO.NET的postgresql，与其他类似的应用程序相比，性能惊人。我发现Dapper会有很多帮助，而且我正在寻找。但是我在哪里放sql代码有困难。好吧，我有模型类..像客户，奥德等...那么我应该把SQL代码放在哪里？我应该把CRUD代码放在不同的类吗？目前我在控制器类中有一些代码但是当我想要的时候我总是构造一个新的控制器类。这似乎不太好 是否有任何模式如何组织数据库代码？

Answer 1

您可能想要考虑使用业务逻辑层，数据访问层和用户界面的N层应用程序。更多详情：http://en.wikipedia.org/wiki/Multitier_architecture

我会这样做，并通过DAL（数据访问层）访问我的所有存储过程或SQL代码（或LINQ-To / EF）。

但是，如果您正在使用Web服务（我猜您只有UI和BL层），则可能没有必要 - 只需调用Web服务并执行您需要对结果执行的操作。

因此，您的应用程序将仅是UI和BL。 BL调用web服务（就像你有一个调用DAL一样），检索数据并完成它需要做的事情。

只有当BL处理请求/响应并与DAL通信以将数据传回应用程序时，您的Web服务才会成为BL和DAL。

Answer 2

  

我应该把sql代码放在哪里，我应该把CRUD代码放在一个   分开上课？

是的，请查看Repository pattern - 您的数据代码应该是独立的，并返回Customer之类的对象。 Entity Framework或NHibernate可以提供合适的功能并且是行业标准。

你也可以放一个Service Layer，从你的多个前端调用。

请确保在图层之间使用DI以减少紧密耦合，我现在喜欢StructureMap但是有很多好的框架。

顺便说一下，你也可以在MVC中使用MVVM模式。

Answer 3

你的后端部分需要提供以下功能：

1. 与客户一起操作：处理来自客户端的请求并将响应发送回客户端。这里的主要问题是定义请求/响应格式。您可以使用SOAP或REST，例如，.NET框架服务框架（如WCF）可以与这两种协议一起使用，但对我而言，它更加面向SOAP。 WCF使用类来描述服务契约，所以我认为最好使用一些实体而不是纯ADO.NET

2. 通知客户有关错误的信息：包括验证错误和例外。验证消息需要在客户端上显示，通常通过属性名称，也应该处理异常。此外，处理与数据库相关的错误并将其转换为域模型错误也存在问题。

3. 基于services的WCF架构 - 它是契约，其实现由一组协议访问。由于WCF使用实体序列化和反序列化，因此将任何业务逻辑放入实体并不是一个好主意。将它放在单独的类（repositories）中，并从您的服务中调用存储库。它被称为anemic domain model - 域实体不包含任何业务逻辑 - 与rich domain model相反 - 实体包含业务逻辑。

4. 对数据库的访问通常封装在一组名为数据访问层（或DAL）的类中。 DAL提供了持久化实体到数据库或从数据库加载实体所需的一组方法。此方法不应包含业务逻辑，而是从业务逻辑层封装数据库详细信息和结构。实现经常使用的图层帮助工具：如ORM（实体框架，BLToolkit等）。

5. 业务逻辑层（BLL） - 使用DAL中的方法来持久化实体。它不应该直接与数据库一起使用 - 只需从DAL调用方法。业务逻辑包含实体和实体集的所有操作 - 包括验证，计算，权限检查等。

编辑

为了支持事务，您可以使用从TransactionScope等数据库类或ORM内置的事务支持中解耦。

让业务逻辑相对不依赖于DAL操作总是好的 - 即业务层流程实体以其不知道实体的方式将被保存。如果可能的话，您可以将数据库事务封装在DAL中 - 但是这可能必须使用包含大量参数的丑陋方法并传递大量实体和集合以保存内部事务。

但通常不可能，业务逻辑层方法几次调用DAL操作 - 加载并保存其他实体。在这种情况下，交易范围或ORM类似物是一个不错的选择。