面向对象的设计:保存复杂的对象 [英] Object-oriented design: Saving complex objects
问题描述
我在遗留系统之上构建了一个复杂的域模型，该遗留系统已经为大多数遗留系统构建了获取"方法-通常仅通过传递数据库主键ID即可.很简单.我现在很好奇如何处理在数据库中创建新对象并用新数据保存现有对象的任务，并希望确保覆盖所有基础.
I have a complex domain model built on top of a legacy system that I've built most of the "get" methods for - typically just by passing around database primary key IDs. Easy enough. I'm now curious how to approach the task of creating new objects in the database and saving existing ones with new data and want to make sure I cover all my bases.
与整个项目中大约20-25的数据库中的实体相对应的主要域对象.大约需要保存10个左右(其余的仅用于支持数据，不需要用户进行更新).要保存的对象具有复杂的依赖性-对象A具有对象B的列表，其中包含对象C，D和E，例如，当原始对象A被保存时，可能需要保存所有这些对象.
The main domain objects that correspond to entities in the database number around 20-25 for the entire project. About 10 or so will need to be saved (the rest are just there for supporting data and don't need updating by the user). The objects to be saved have complex dependencies - object A has a list of object B which contains objects C, D, and E, for example, all of which might need to be saved when the original object A is.
我想对其进行构建，以便UI开发人员可以轻松使用它，而且还强制执行仅保存有效数据的操作(例如，除非对象C处于有效状态，否则对象B可能无法保存).这让我避开了让他们从头开始创建对象并尝试保存它的想法-我想遵循一个原则，即对象只能在有效状态下存活.
I'd like to build it so it's easy to use by the UI developer, but also enforces that only valid data gets saved (let's say maybe object B cannot save unless object C is in a valid state). This makes me shy away from allowing them to create an object from scratch and attempt to save it - I want to follow the principle that objects should only ever be alive in a valid state.
另一种选择是在处理它们的服务对象上公开"CreateNew"和"Save"方法，但是此类方法的参数列表会非常糟糕.
The other alternative is exposing "CreateNew" and "Save" methods on the service objects that handle them, but the parameter list for such methods would be egregious.
我正在考虑要求"CreateNew"和"Save"接受可以创建和传递的命令对象之类的东西，以便他们确切地知道需要什么数据以及他们无法尝试控制什么.我阅读了命令模式，但是我不需要它提供的任何主要好处
I'm thinking of requiring "CreateNew" and "Save" to accept something like a command object that they can create and pass so they know exactly what data is needed and what they can't try to control. I read up on the command pattern but I don't need any of the main perks it provides.
在确定方法时，我应考虑哪些因素?如果是C#3.5的话，那就是C#3.5.
What considerations should I have to decide on an approach? This is C#3.5, if that factors into it at all.
推荐答案
您应该研究.NET流行的对象关系映射框架.以前有很多人处理过这个问题，有些最聪明的人已经与我们分享了自己的劳动成果.他们有很多功能，最受欢迎的功能已经过严格的测试.
You should investigate the popular object-relational mapping frameworks for .NET. A lot of people have handled this problem before, and some of the smartest ones have shared the fruits of their labor with us. They've got loads of features and the most popular ones are heavily tested.
似乎每隔几天，会有新来的人要求.NET ORM建议，因此有很多Stack Overflow主题可以帮助您进行指导.例如:
Every few days, it seems, someone new asks for .NET ORM recommendations, so there are plenty of Stack Overflow topics to help guide you. For example:
- What are your favorite .NET Object Relational Mappers (ORM)?
- What ORM frameworks for .NET Do You Like Best?
- Which ORM for .net would you recommend?
(如果您在"ORM"和".NET"上进行搜索，则会发现更多匹配项.)
(If you search on 'ORM' and '.NET' you'll turn up many many more matches.)
在典型用法中，UI开发人员仅处理高级父对象(在域驱动设计的语言中称为聚合根").他们将ORM用作存储库，并确保给定保存中的所有操作都捆绑在一起在明智的交易中. (您仍然需要根据域对象中的业务规则强制执行有效性.)
In typical usage, the UI developer only deals with high-level parent objects (called 'aggregate roots' in the language of Domain-Driven Design). They use the ORM as a Repository and it ensures all the operations in a given Save are bundled together in sensible transactions. (You still need to enforce validity per business rules in your domain objects.)
下面是UI代码的简化视图:
Here's a simplified look at what UI code would look like:
// Given an IRepository implemented by your ORM,
ICustomer customer = repository.Get(customerId);
// ... do stuff to customer and its child objects ...
repository.Save(customer);
这篇关于面向对象的设计:保存复杂的对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
