1

作为一名开发人员，我试图让我的类更加模块化和可重用。我遇到问题的一个领域是当我设计一个类来处理实体框架实体时。

例如，我可能会创建一个购物车类，它的角色是充当产品、折扣和其他与结帐相关的东西的容器。它公开了获取购物车总数的方法，并执行一些与购物车可以做什么和不能做什么相关的业务规则。

我可能会创建一个“产品”的实体框架实体，并让我的购物车接受这个实体。无论这看起来多么方便，它都会对我正在使用购物车的项目中的 Product 类产生不必要的依赖。如果我想将该购物车重新用于另一个项目，则“产品”实体不一定是相同的。

我怎样才能优雅地将我的购物车类与实体框架分离，并且不会在未来引起架构问题？

我想创建一个接口 IProduct，它具有购物卡所需的相关属性和方法，然后使我的实体类成为 IProduct 的实例。

基本上，我正在寻找一种好的设计模式来将我的类与项目的本地域实体分离，无论它们可能采用什么形式......

这就是我最终的结果；T 是 IProduct 的通用购物车。然后我将我的实体框架实体设为 IProduct：

public interface IProduct
{
    /// <summary>
    /// Unique Identifier For the product.
    /// </summary>
    int Id { get; set; }
    decimal Price { get; set; }
}

public interface IShoppingCart<T> where T : IProduct
{
    /// <summary>
    /// Returns the total of all the products without any modifiers.
    /// </summary>
    decimal SubTotal { get; }

    /// <summary>
    /// Returns a total of everything in the cart, including all applicable promotions.
    /// </summary>
    decimal Total { get; }

    /// <summary>
    /// Returns a total of the discounts for the applicable promotions in the cart.
    /// </summary>
    decimal TotalDiscount { get; }

    /// <summary>
    /// Returns a count of products in the cart.
    /// </summary>
    int ProductCount { get; }

    /// <summary>
    /// Returns a count of unique products in the cart.
    /// </summary>
    int UniqueProductCount { get; }

    /// <summary>
    /// Adds a product increasing the product count if there is already one in the cart.
    /// </summary>
    /// <param name="product">Product To Add</param>
    void AddProduct(T product);

    /// <summary>
    /// Remove an instance of a product from the cart, return the product that was removed.
    /// </summary>
    /// <param name="id"></param>
    /// <returns>Instance of T</returns>
    void RemoveProduct(int id);

    /// <summary>
    /// Returns a list of the products in the cart.
    /// </summary>
    /// <returns></returns>
    IList<T> ListProducts();

    /// <summary>
    /// Remove all products from the cart;
    /// </summary>
    void ClearAllProducts();

    /// <summary>
    /// Add a promotion strategy to the cart.
    /// </summary>
    /// <param name="promotion"></param>
    void AddPromotion(IPromotion<T> promotion);
    /// <summary>
    /// Remove a promotion from the cart.
    /// </summary>
    /// <param name="promotion"></param>
    void RemovePromotion(string key);
    /// <summary>
    /// Remove all promotions from the cart.
    /// </summary>
    void ClearAllPromotions();

    /// <summary>
    /// List all of the promotions currently in the cart.
    /// </summary>
    /// <returns></returns>
    IList<IPromotion<T>> ListPromotions();

    /// <summary>
    /// Remove everything from the cart (promotions and all).
    /// </summary>
    void EmptyCart();
}
4

3 回答 3

1

您可以使用实体框架的“代码优先”功能。它允许您使用代码创建域类并将它们映射到数据库表。您可以在这些类中拥有方法、附加属性等。

http://msdn.microsoft.com/en-us/data/gg685467.aspx

有一些限制，例如每个类必须有一个默认构造函数，并且关联属性必须是虚拟的。但它们并没有那么成问题。

于 2013-05-12T17:59:18.037 回答
1

一种方法是拥有两组类，一组代表您的 POCO 类，另一组代表实体框架类。您的 POCO 类将是 Cart、Product 等，并且将包含所有业务逻辑，并且当您想要将 Product 写入数据库时​​，例如，您可以将 Product POCO 类手动或手动转换为实体框架产品类AutoMapper 等框架。

作为一个想法，您可以有一个类来包装实体框架数据上下文，并公开诸如 AddProduct 之类的方法，这些方法将接受 POCO 类的实例。然后，此方法会将其转换为实体框架产品实例并将其写入数据库。

这种方法的缺点是您必须将 POCO 实例转换为实体框架实例，但它允许您将 POCO 类与实体框架类分开使用。另外，您可以在不考虑数据库架构的情况下定义您的 POCO。当您调用 AddProduct 并执行从 POCO 到 Entity Framework 的转换时，您可以决定如何将 POCO 实例写入数据库。

编辑：另一种方法是按照@Dmitry S 的建议使用 Code-First，但 Code-First 促进了 Convention-over-Configuration 方法，这可以在您创建 POCO 类时强制执行某些设计理念。

于 2013-05-12T18:19:41.173 回答
1

您在IProduct界面的想法上走在了正确的轨道上。

我会将可重复使用的购物车放在自己的程序集中——一个不知道持久性的程序集（例如实体框架）。购物车程序集将包含IProduct您的应用程序产品必须实现的接口。通过这种方式，购物车逻辑可以对使用它的应用程序（通过接口）设置要求。

如果您需要持久化购物车，则必须将该持久化逻辑放在域层中。一种选择可能是将购物车用作代码优先实体，另一种是将数据映射到作为 Db 模型一部分的实体类。

于 2013-05-12T18:28:04.427 回答