有点宽泛的问题。使用ORM技术(也许是NHibernate?)将数据库与业务逻辑(可怕的术语)分开。那就让你大部分(很明显)呆在OO的土地上,从架构的角度来看,你可以忽略事物的DB方面。

继续前进,我发现领域驱动的设计( DDD )作为将复杂系统分解为可管理的块的最成功的方法,尽管它没有得到尊重,但我真诚地发现UML(尤其是动作图和类图)在理解和通信系统设计中非常有用。

一般性建议:接口所有东西,从一开始就构建单元测试,并学习识别和分离可以作为子系统存在的可重用服务组件。fwiw如果有很多人在这方面工作,我也会同意并积极使用get-go中的stylecop:)

我发现,当将复杂的业务逻辑拆分为更具可管理性/可测试性的块时,域驱动设计的一些实践非常优秀。

通过以下链接查看示例代码:

http://dddpds.codeplex.com/

DDD关注你的域层或者BLL,如果你愿意的话,我希望它能有所帮助。

我们只是从体系结构的角度来讨论这个问题,它的核心仍然是“抽象、抽象、抽象”。

你可以用 EBC 自上而下设计并将接口定义传递给程序员团队。使用类似这样的方法(或任何其他可视化技术)可视化依赖项,可以防止在项目中的任何地方复制业务逻辑。

嗯,我可以告诉你我们在一个很大的以数据库为中心的应用程序中使用的技术。我们有一个类,按照您的建议管理数据层,它有后缀dl。我们有一个程序可以自动生成这个源文件(这非常方便),尽管这也意味着如果我们想要扩展功能,您需要派生类,因为在源文件重新生成之后,您会覆盖它。

我们有另一个以obj结尾的文件,它简单地定义了由数据层处理的实际数据库行。

最后但并非最不重要的是,对于一个格式良好的基类,有一个以bs结尾的文件(代表业务逻辑)作为唯一没有自动生成的文件,它定义了诸如“new”和“save”这样的事件方法,这样通过调用基,默认操作就完成了。因此,任何与规范的偏差都可以在这个文件中处理(包括必要时对默认功能的完全重写)。

您应该为每个表及其从主表派生的子表(或孙子表)创建一组这样的文件。您还需要一个包含所有对象全名的工厂,以便通过反射创建任何对象。因此,要修补程序,您只需从基本功能派生,并更新数据库中的一行,这样工厂就可以创建该对象,而不是默认对象。

希望这能有所帮助,不过我会留下一个社区wiki回复,这样也许你可以得到更多关于这个建议的反馈。

看看这条线。可以给你一些想法。

How should my business logic interact with my data layer?

这个 guide from Microsoft 也会有帮助。

关于“编辑1”-我已经多次遇到这个问题。我完全同意你的观点:在许多地方必须进行相同的验证。

我过去解决这个问题的方法是以某种方式封装验证规则。元数据/XML,单独的对象,无论什么。只要确保它是可以从业务对象请求的,可以在其他地方执行。这样,您只需编写一次验证代码,它就可以由业务对象或UI对象执行,甚至可能由代码的第三方消费者执行。

有一个警告:一些验证规则很容易封装/传输;“姓氏是必需字段”例如。但是,您的一些验证规则可能过于复杂,涉及的对象太多,无法在元数据中轻松封装或描述:“只有当用户不是员工时,用户才能包含该优惠券,并且订单在劳动节周末下达,并且他们具有此par的2到5项。在他们的购物车中输入特定的类型,除非他们的购物车中也有这些其他物品,但只有当颜色是我们的“首映式销售”颜色之一时,除了布拉布拉布拉布拉布拉………“-你知道业务“逻辑”是什么样的!;

在这些情况下,我通常只接受这样一个事实,即只有在业务层才会进行一些额外的验证,并确保有一种方法可以在这些错误发生时将其传播回UI层(无论如何,您都需要该通信通道,以报告回波斯臭气层出错)。