ASP.net MVC：我应该在设计中的何处创建/声明实体键？
创建具有外键值的新实体对象时，我需要为该对象创建一个新的实体键（.net 3.5 中的实体框架），但我无法决定应该在应用程序中的何处执行此操作。
现在，当我使用外键创建新记录时，我在控制器中创建实体键（在本例中是从成员资格提供程序中提取的用户 ID），将其分配给对象并将其传递给 repository< /strike> 服务层。
这是否有任何问题，或者我应该将对象加上用户 ID 传递到 repository 服务层并让它处理实体密钥创建？传递一个对象看起来更干净，但是让多个控制器以这种方式分配键让我感到紧张。谢谢。
When creating a new entity object that has a foreign key value I need to create a new Entity key (Entity Framework in .net 3.5) for the object, but I'm having trouble deciding where in my application I should do this.
Right now when I create a new record with a foreign key, I create the entity key in the controller (in this case a user ID pulled from a membership provider), assign it to the object and pass it to the repository service layer.
Are there any problems with this, or should I be passing the object plus the user ID to the repository service layer and have it deal with the entity key creation? Passing one object seems cleaner, but having multiple controllers assigning keys this way makes me nervous. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这是一个关注点分离的问题。存储库涉及检索和添加/更改/删除实体。它不应该负责构建实体。相反，控制器实际上也不应该负责构建实体（控制器应该完成将数据推送到视图所需的基本工作量，并处理视图中的命令，将这些命令委托给业务逻辑...业务逻辑属于其他地方（如域）。）老实说，您应该创建某种类型的 EntityBuilder 来处理创建实体的过程。您可以将对象加上用户 ID 传递给构建器，然后构建器将为您提供一个完全构建的实体，然后可以将其传递到存储库。
编辑：
即使您从“存储库”更改为“服务层”，主体仍然保持不变。将构建实体的过程委托给专门的构建者，并保持关注点分离。
I think this is a matter of separation of concerns. A repository is concerned with retrieving and adding/changing/removing entities. It shouldn't be responsible for building entities. Conversely, the controller really shouldn't be responsible for building entities either (a controller should to the bare-bones amount of work required to push data to a view, and handle commands from a view delegate those commands to business logic...business logic belongs elsewhere (like a domain).) In all honesty, you should create an EntityBuilder of some sort to handle the process of creating entities. You would pass the object plus user ID to a builder, which would then provide you with a fully built entity that could then be passed on to a repository.
EDIT:
Even with your change from 'Repository' to 'Service Layer', the principal remains the same. Delegate the process of building your entity to a dedicated builder, and maintain your separation of concerns.