MVC：如何与许多子实体的实体工作？ [英] MVC: How to work with entities with many child entities?

问题描述

在上ASP.NET MVC当前例子我看到很基本的实体，具有简单的CRUD方法。

但我不知道做什么用更先进的模型做的。让我举一个例子：

In the current examples on ASP.NET MVC I see quite basic entities, with simple CRUD methods.
But I'm not sure about what to do with more advanced models. Let me give an example:

我们有一个车库网站。车库有：

We have a garage website. The garage has:

• 库存与 carparts


• 员工


• 客户


• 汽车，它包含了全部的汽车/是在车库

• Inventory with carparts
• Employees
• Customers
• Cars that consists of all cars that are/were in the garage

现在让我们在车，车上可能有员工集合上车的工作（派生从原来的员工类，增加了一些额外的道具的牵绊车）， carparts 的集合，有被替换（也派生，例如SerialNr和 ReplacementDate 道具增加了），当然还有客户的道具客户whoe拥有汽车。

Now lets take the car, the car might have a collection of employees that worked on the car (derived from the original employee class, adds some extra props that tie him to the car), a collection of carparts that have been replaced (also derived, adds for example SerialNr, and ReplacementDate prop) , and of course a customer prop of the customer whoe owns the car.

现在在休息我想看到以下内容：

Now in rest I would like to see the following:

/cars/423 [get]                  //show car # 423
/cars/423/edit [get]             //shows the edit form (ajax enabled, so also shows the other props)
/cars/423/carparts [get]          //gets the carparts inside the car
/cars/423/carparts/32/edit [post] //updates that specific carpart inside the specific car
/cars/423/employees [get]         //gets the employees who worked on the car
/inventory [get]
/inventory/1234/edit [get]        //gets the update form for carpart with ID 1234                   
/employees [get]                  //gets all the employees in the company

那么我将如何建立我的控制器？我要补充全部为 CarsController 中的子元素的CRUD方法？不使因为几十方法极其肥胖控制器（这种模式过于简化了，车上有更多的父子关系）？或者我应该创建一个 EmployeesInCar 控制器（似乎不好）...
非常感谢。

So how would I build my Controllers? Should I add all those CRUD methods for the child elements inside the CarsController? Doesn't that make a very fat controller because of the tens of methods (this model is overly simplified, the car has many more parent-child relationships)? Or should I create a EmployeesInCar controller (seems bad)... Thanks a lot.

编辑：

首先示例的唯一是假设，只是一个例子。

如果我按照我的建议将有一个 CarController 只处理汽车。而我PartsController将只处理部件。但是，我们有两套部分 S，一般一个（库存）;我们有一个部分 A车，这从一般的派生，但增加了属性，如的SerialNumber 并在 ReplacementDate

所以我的部件控制器变得比较胖，该示例让我们把实体：GeneralPart（库存）和SpecificPart（派生类，具有额外的属性）

First of all the example is hypothetical only, just an example.
If I follow the suggestion I would have a CarController which only handles cars. And my PartsController would handle only Parts. But we have two sets of Parts, a general one (for the inventory); and we have a Part inside a car, which derives from the general one, but adds properties such as SerialNumber and ReplacementDate.
So my Parts controller becomes quite fat, for the example let's call the entities: GeneralPart (in inventory) and SpecificPart (the derived class, with the extra properties)

Index -> Returns all GeneralParts in inventory.
IndexByCar(int id) -> Return all SpecificParts by Car.
etc. etc.

由于每一个行动无论是一般部分或特定部分交易。这同样适用于员工，我们有基础Employee类，和特定一体，具有额外的属性。

Because each action deals with either a General Part or a Specific Part. The same is for employees, we have the base employee class, and a specific one, with extra properties.

推荐答案

如果您希望使用各种你在你的例子所提供的线路，那么这听起来像你应该学会如何使用路由引擎在.NET 3.5。您应该能够使用各种你需要的网址，但你需要创建多个自定义路线和可能一个自定义的路由处理程序来完成它。在.NET 3.5路由引擎非常灵活，没有为MVC专...它实际上是非常通用的，可以提供URL重写的一个非常广泛的，可能是无限的范围。

If you wish to use the kinds of paths you provided in your example, then it sounds like you should learn how to use the Routing engine in .NET 3.5. You should be able to use the kinds of urls you need, but you will need to create several custom routes and probably a custom route handler to accomplish it. The Routing engine in .NET 3.5 is very flexible and was not designed specifically for MVC...its actually very generic and can provide a very broad, probably unlimited range of url rewriting.

它有点晚了，我住的地方，这样的例子我试图写只是不成型。 ：P我只想说，一个自定义的路由处理程序和一些新的路径映射应该把你带到任何你需要。

Its a bit late where I live, so the example I was trying to write just isn't forming. :P Suffice to say, a custom route handler and some new route mappings should get you where you need to be.

编辑：这可能会有所帮助：

This may be of help:

http://codingcockerel.co .UK / 2008/5月26日/自定义路由为-ASP净MVC /

编辑2：
我之前离开了控制器。路由只是让你使用你种希望网址的能力。并且那是一件好事......建议将提供更好的SEO体验长期受制于人的URL的你。作为组织你的控制器，我建议保持简单：

EDIT 2: I left out controllers before. The routing just gets you the ability to use the kinds of URLs you want. And thats a good thing...the kinds of URL's you proposed will provide a better SEO experience long-term. As for organizing your controllers, I recommend keeping it simple:

/Controllers/CarsController.cs
/Controllers/PartsController.cs
/Controllers/EmployeesController.cs
/Controllers/InventoryController.cs

您的路线将匹配您的网址模式，并把他们变成你的控制器合适的路由，取ID和他们匹配你的行为的参数。

Your routes would match your url patterns, and turn them into a proper route to your controller, taking the ID's and matching them to the parameters of your actions.

编辑3：

所以，现在我更全面地了解你的问题，我希望我可以更好地回答这个问题。总体来说，我觉得控制器应该映射1：1与你的实体。如果你有一个GeneralPart，那么你应该有一个专门管理通用零部件的控制器。如果你有CarPart，那么你应该有一个专门管理汽车零部件控制器。如果CarParts是GeneralParts，他们可以表现得像在某些情况下GeneralParts，那么它可能是最好的对GeneralPartsController的管理方面，除非管理处理一个CarPart的任何特殊属性......在这种情况下，管理应委托到CarPartsController。它是一种优雅多态性如何发挥到控制器的组织，以及如何是的关系，可以重复使用的控制器来管理多个类型。

So, now that I understand your question more fully, I hope I can answer it better. Generally speaking, I think controllers should map 1:1 with your entities. If you have a GeneralPart, then you should have a controller dedicated to managing general parts. If you have CarPart, then you should have a controller dedicated to managing car parts. If CarParts are GeneralParts, and they can behave like GeneralParts in some cases, then it is probably best to have those management aspects on the GeneralPartsController, unless that management deals with any special attributes of a CarPart...in which case management should be delegated to CarPartsController. It is kind of elegant how polymorphism plays into controller organization, and how the "is a" relationship allows you to reuse controllers to manage multiple types.

说实话，你有一个相当复杂的情况我没有带直接在我的时间遇到​​了ASP.NET MVC工作。我会尽量避免这样的情况下尽可能的，因为它们产生的往往是主观的在他们的答案是这样复杂的问题。最终，你应该以组织的方式，使逻辑意义上它们是如何使用，他们是如何映射到实体的控制器，以及他们如何组织好你有兴趣揭露的行为。有时候，这是不符合逻辑的所有控制器映射到一个单一的实体。有时候，你需要有一个复合的控制器与实体，在一次对多个实体进行操作的行为，或图形的交易。在这种情况下，它可能是最好有专门为这些特定的行为组，控制器，而不是试图找到一个具体的实体控制器八九不离十适合。

To be honest, you have a fairly complex scenario I havn't directly encountered in my time working with ASP.NET MVC. I try to avoid such scenarios as much as possible, because they give rise to complicated questions like this that tend to be subjective in their answers. Ultimately, you should organize your controllers in a way that makes logical sense to how they are used, how they map to your entities, and how well they organize the behavior you are interested in exposing. Sometimes, it isn't logical to map all of your controllers to a single entity. Sometimes you need to have a "composite" controller that deals with actions that operate on multiple entities at once, or graphs of entities. In these cases, its probably best to have controllers dedicated to those particular behavioral groups, rather than trying to find one entity-specific controller that "sorta fits".

这篇关于MVC：如何与许多子实体的实体工作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！