用于数据访问的简单 API
我们希望创建一个 API，它将包装模型和存储库之间的所有内部交互，并提供一种简单的方法来添加和更新系统内的实体。
我正在沿着这个 API 的消费者的路线寻找：
SystemOder order = SomeClass.GetSystemOrderById("...");
order.amount = 200;
order.InvoiceAddress[0].StreetName = "123 Fake Street";
order.Save();
现在，在幕后，我们仍然是存储库架构的模型，但为了编写纯业务逻辑，它将位于最终消费者之上并将其隐藏起来。这种架构有什么合适的模式吗？
只是为了澄清，我们显然不想将 Save() 方法烘焙到核心域模型或类似的东西中，我们只是想要一个好的 API 来删除解析集合和调用存储库等不必要的代码。
We're looking to create an API that will wrap all internal interactions between our model and repositories and provide a simplistic way to add and update entities within the system.
I'm looking along the lines of the consumers of this API to be able to go:
SystemOder order = SomeClass.GetSystemOrderById("...");
order.amount = 200;
order.InvoiceAddress[0].StreetName = "123 Fake Street";
order.Save();
Now behind the scenes we still a model to repository architecture but for writing pure business logic this would sit on top of and hide it from end consumers. Are there any decent patterns for this kind of architecture?
Just to clarify we obviously don't want to bake in Save() methods into or core domain model or anything like that we just want a nice API to strip out needless code resolving collections and calling repositories etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来您正在寻找类似存储库模式的东西。 （您在问题中提到了存储库，但我认为您正在使用该术语代替数据存储？）
引用 Martin Fowler 的描述。
使用类似集合的接口来访问域对象，在域和数据映射层之间进行中介。
更多信息可以在此处找到
It sounds like you are looking at something like the repository pattern. (You refer to repositories in your question but I think you are using the term in place of a data store?)
To quote Martin Fowler's description.
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
More info can be found here
将推出我自己的外观模式，该模式将封装对象模型和 Save()、Delete 等持久机制，同时仍然保持模型/DAL 的良好分离。这是 mixin 非常有用的类型……哦，好吧。
Going to roll my own facade pattern that will encapsulate the object model and the persistence mechanisms of Save() Delete etc while still maintaining a good seperation of model/DAL. It's the type of thing mixins would be extremely useful for...ohh well.