Spo*_*ted 9 c# nhibernate domain-driven-design fluent-nhibernate fluent-nhibernate-mapping
我正在编写一个 POS(销售点)软件,它允许支付货物或退款。在付款或退款时,需要指定使用哪种汇款方式:现金、EFT(~=信用卡)、会员卡、代金券等。
这些汇款方式是一组有限且已知的值(一种枚举)。
棘手的部分是我需要能够在 POS 终端上存储这些方式的自定义子集,用于付款和退款(两组可能不同)。
例如:
我选择实现汇款方式的概念如下:
public abstract class MoneyTransferMean : AggregateRoot
{
public static readonly MoneyTransferMean Cash = new CashMoneyTransferMean();
public static readonly MoneyTransferMean EFT = new EFTMoneyTransferMean();
// and so on...
//abstract method
public class CashMoneyTransferMean : MoneyTransferMean
{
//impl of abstract method
}
public class EFTMoneyTransferMean : MoneyTransferMean
{
//impl of abstract method
}
//and so on...
}
Run Code Online (Sandbox Code Playgroud)
它不是“普通枚举”的原因是这些类内部存在一些行为。我还必须将内部类声明为 public(而不是私有),以便在 FluentNHibernate 映射中引用它们(见下文)。
支付和退款手段总是作为一个集合存储在/从数据库中检索。它们实际上是两个不同的集合,即使两个集合中的某些值可能相同。
用例 1:定义一组新的支付/退款方式
用例2:检索所有支付/退款方式
我在持久性方面坚持我目前的设计。我正在使用 NHibernate(使用 FluentNHibernate 来声明类映射),但找不到将其映射到某些有效数据库模式的方法。
我发现可以使用entity-name多次映射一个类,但是我不确定子类是否可行。
我还没有准备好改变 MoneyTransferMean 公共 API 以使其能够持久化(例如,添加一个bool isRefund以区分两者)。但是,添加一些私有鉴别器字段左右就可以了。
我目前的映射:
public sealed class MoneyTransferMeanMap : ClassMap<MoneyTransferMean>
{
public MoneyTransferMeanMap()
{
Id(Entity.Expressions<MoneyTransferMean>.Id);
DiscriminateSubClassesOnColumn("Type")
.Not.Nullable();
}
}
public sealed class CashMoneyTransferMeanMap : SubclassMap<MoneyTransferMean.CashMoneyTransferMean>
{
public CashMoneyTransferMeanMap()
{
DiscriminatorValue("Cash");
}
}
public sealed class EFTMoneyTransferMeanMap : SubclassMap<MoneyTransferMean.EFTMoneyTransferMean>
{
public EFTMoneyTransferMeanMap()
{
DiscriminatorValue("EFT");
}
}
//and so on...
Run Code Online (Sandbox Code Playgroud)
这个映射编译但是它只生成 1 个表,在查询这个表时我无法区分付款/退款。
我试图声明两个映射,同时引用MoneyTransferMean不同的表和实体名称,但这导致我出现异常Duplicate class/entity mapping MoneyTransferMean+CashMoneyTransferMean。
我还尝试复制子类映射,但无法指定“父映射”,这导致我遇到与上述相同的异常。
是否存在保留我当前域实体的解决方案?
如果不是,我需要对我的实体执行的最小重构是什么,以使它们与 NHibnernate 保持一致?
MoneyTransferMean最后,我决定通过将我的实体复制为两个实体PaymentMean和来解决问题RefundMean。
尽管在实现上相似,但这两个实体之间的区别在业务中是有意义的,并且对我来说是最不糟糕的解决方案。