基础商务舱:坏吗?

很多人赞成 Single Responsibility Principle

很糟糕。我们已经这样做了好几年了,我们在基类中没有任何东西可以通用到可以应用于所有继承类。

从面向对象设计的角度来看,这可能不是最优雅的解决方案,但如果要使用数据绑定,通常最好在基类中实现INotifyPropertyChanged。这样,您就可以最小化在所有实体中实现它的负担。

Unit of Work 模式(pattern),如果您希望将此职责与基类分离,尽管在不依赖于ORM的.net应用程序中看到实现更改跟踪是非常常见的。

如果业务实体不需要从这些基类派生,那么拥有一组接口和基类来实现那些接口,这些接口提供一些您希望在业务实体中使用的通用功能,我认为这并不一定是坏事。这为您提供了灵活性,同时提供了实现的便利性。

例如,我有一个IValidatedEntity接口,它几乎应用于我创建的每个业务对象。它要求业务对象实现一些验证规则。但是,我的审计对象只在内部创建,我使用单元测试来确保我不能创建无效的审计对象,这样这些类就不会实现IValidatedEntity接口

我的大多数从web获取输入并包含字符串数据的类都来自XSSValidatedEntity类(它实现了IValidatedEntity接口),但是通过HTML解析器提供XSS检查,以防止将HTML注入数据库。对于我的大多数类来说,这工作得很好,但是在那些我希望允许有限(安全)HTML的情况下,我显然不能从这个类派生。

您描述的内容听起来更像一个表示对象,但是IsDirty和IsNew也可以用于域模型。在决定在基本对象中包含什么之前,您应该清楚地了解业务需求是什么。先关注一下业务对象,需求会有多静态?你是否掌握了控制对象交互方式的所有规则,这些规则是否会改变?如果他们改变,多久一次?这对你来说可能是最具挑战性的

您可能会发现,根据应用程序的不同,您的大部分工作应该来自于实现业务流程,从而实现CRUD功能的体系结构。虽然重要,但不是你努力的重点。换句话说,您的业务对象将支持业务流程的概念,而不包括IsDirty。然后,数据访问层可以集中于记录的状态,并确定是插入还是更新数据。