建立DAL使用EDM（来自数据库） [英] Building DAL. Using EDM (from database)

问题描述

我必须开发一个在Windows（wpf）中工作的lob应用程序，但应该部署在两个方面：

I have to develop an lob application that works in windows (wpf) but should be deployed in two flavors:

• 数据库（同一台计算机）


• 使用远程数据库（在同一网络中）

将使用从数据库生成的实体数据模型（dbcontext，EF 4.0）（VS2012，sql server express 2012）

I'll use Entity Data Model generated from a database (dbcontext, EF 4.0) (VS2012, sql server express 2012)

我想开发一个唯一的数据访问层， UI将被绑定，并且将直接从dbcontext（本地数据库）获取数据，或者从公开数据从dbcontext（远程数据库）的WCF服务获取数据。

I want to develop a unique Data Access Layer which the UI will be bound to, and it will take the data from the dbcontext directly (local database) or from a WCF Service that exposes the data from a dbcontext (remote database)

我不知道从哪里开始，我需要指导，例子，我知道这取决于应用程序的性质，但一些例子，文章将会有很大的帮助。我没有找到一个类似于我的需求的例子

I don't know where to start, I need guidance, examples, I know that it depends on the nature of the application, but some example, article, would be of great help. I don't find an example that's similar to my needs

我想我最好使用DI框架，但是我想先重点关注DAL。 >

I guess that I better use a DI Framework, but I want to focus on the DAL first.

推荐答案

嗯，既然你想使用DI框架（可能是一个很好的选择:)），你已经知道你需要定义你的DAL使用接口。然后，您可以使用实现这些接口的类作为WCF服务或DB上下文的适配器。

Well, since you want to use a DI framework (probably a good choice :)), you already know that you need to define your DAL using interfaces. Then you can have classes implementing those interfaces that act as adapters to either the WCF Service or the DB Context.

设计的一个不错的方面是，您将自动隔离自己从将来可能更换WCF服务和数据库上下文 - 即每当Microsoft发布另一种数据访问技术时。 :)或者更有可能，当你的团队决定采用不同的，例如从WCF服务切换到REST服务。

A nice aspect of your design is that you will automatically isolate yourself from possible future replacements of WCF Service & DB Context - i.e., whenever Microsoft releases yet another data access technology. :) Or more likely, whenever your team decides to adopt a different one, e.g. switching from a WCF service to a REST service.

一般来说，存储库模式用于解决这个问题。所以例如你可能有：

In general the Repository pattern is used to solve this. So for example you might have:

public interface IWidgetRepository
{
    // Query methods
    Widget GetById(string id);
    IEnumerable<Widget> GetAll();

    // Update methods
    void RenameWidget(string id, string newName);
    void UpdateWidgetPrice(string id, decimal newPrice);
}

如果您尝试使存储库界面非常笼统，那么这将变得令人生畏很快，当你开始意识到你想有不同的查询功能等（例如，如果你尝试在DAL中实现IQueryable，你有很多工作在你之前！我试过，我放弃意识到我只是在浪费努力。）

If you try to make the repository interface very general, though, this becomes daunting very quickly as you start to realize that you want to have different querying capabilities, etc. (E.g., if you try to implement IQueryable in the DAL, you've got a lot of work ahead of you! I've tried, and I gave up realizing that I was just wasting effort.)

最好的方法可能是有预定义的查询方法，例如 GetWidgetsWithOpenOrders（）和 GetWidgetsWithFooBarComponents 。然后在实现 IWidgetRepository 的适配器类中，您只需将它们映射到实体框架或WCF服务实现即可实现这些查询。

The best way around that is probably to have predefined query methods, e.g. GetWidgetsWithOpenOrders() and GetWidgetsWithFooBarComponents. Then in your adapter classes that implement IWidgetRepository you'll just have to implement those queries by mapping them to either the Entity Framework or WCF Service implementations.

这样做的一个副作用是DAL将需要自己的一组数据传输对象（DTO） - 所以你最终会在DAL命名空间中使用一个Widget类，并可能有其他的数据库上下文和/或WCF服务代理中的小部件类。您可以尝试通过强制DB上下文为其数据库映射使用相同的Widget类来解决这个问题，但我不会推荐它。数据库环境中的DTO有适应数据库的需要，而WCF服务中的DTO也是如此 - 它们是服务所暴露的数据合同。 DAL中的DTO是为了反映用户界面的需求（在MVVM中，它们是模型;在OO模式中它们是一个外墙在不同的数据访问策略）。

One side effect of this is that the DAL will need its own set of data transfer objects (DTOs) - so you'll end up with a class for Widget in the DAL namespace, and potentially have other Widget classes in the DB Context and/or the WCF Service proxy. You can try to work around that by forcing the DB Context to use the same Widget class for its database mapping, but I wouldn't recommend it. The DTOs in the DB Context are there to adapt to the database, and the same goes for the DTOs in the WCF Service - they're the data contracts that the service exposes. The DTOs in the DAL are there to reflect the needs of the user interface (in MVVM terms, they're the 'Model'; in OO patterns terms they're a Façade over the different data access strategies).

另一个副作用是创建存根/模拟很容易您的 IWidgetRepository 的实现用于1）单元测试，以及2）快速原型化您的UI，而不需要完全实现后端数据访问策略。

Another side effect is that it's very easy to create stub/mock implementations of your IWidgetRepository for 1) unit testing and 2) rapid prototyping of your UI without the back-end data access strategies being fully implemented.

这篇关于建立DAL使用EDM（来自数据库）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！