Efficient way to deal with maintaining Many:Many relationships in EF Code-First
$begingroup$
I've got this all working, but it seems to be quite long-winded, and I thought I'd post here and see if I'm doing it wrong...
I have a M:M relationship between an Installer and a MasterInstance. The classes (code-first) look like:
public class MasterInstance
{
.. rest of fields here ..
public virtual ICollection<Installer> PermittedInstallers { get; set; }
}
public class Installer
{
.. rest of fields here ..
public virtual ICollection<MasterInstance> PermittedMasterInstances { get; set; }
}
I want to be able to edit these in my Installer view, using a multi-list box. So, I create a ViewModel for what I need:
public class InstallerViewModel
{
public Installer Installer { get; set; }
public List<MasterInstance> PermittedMasterInstances { get; set; }
public int SelectedMasterInstances { get; set; }
}
And then I place this in my view like so so that I can select the instances for my installer:
<div class="editor-field">
@Html.ListBoxFor(model => model.SelectedMasterInstances,(Model.PermittedMasterInstances).Select(option => new SelectListItem {
Text = option.Name,
Value = option.MasterInstanceId.ToString()
}))
</div>
In the controller, for the edit action, I need to set this view model up:
var installer = context.Installers.Include(i => i.PermittedMasterInstances).Single(x => x.InstallerId == installerId);
InstallerViewModel model = new InstallerViewModel
{
Installer = installer,
PermittedMasterInstances = context.MasterInstances.ToList(),
SelectedMasterInstances = installer.PermittedMasterInstances.Select(i => i.MasterInstanceId).ToArray()
};
return View(model);
Finally, on the post of the edit, I need to delete any relationships that are no longer there and add the new ones:
// Grab the model from the viewmodel and attach to the context
var installer = installerModel.Installer;
context.Installers.Attach(installer);
// Load the related records (dont know why Lazy Loading wouldn't kick in here)
context.Entry(installer).Collection(i => i.PermittedMasterInstances).Load();
// Iterate and delete existing relationships
var instancesToDelete = installer.PermittedMasterInstances.Where(mi => !installerModel.SelectedMasterInstances.Contains(i.MasterInstanceId)).ToList();
instancesToDelete.ForEach(mi => installer.PermittedMasterInstances.Remove(mi));
// Now loop through an int and add those new relations, WITHOUT the pain of fetching them from the DB
foreach (var permittedMasterInstanceId in installerModel.SelectedMasterInstances)
{
if (!installer.PermittedMasterInstances.Any(pmi => pmi.MasterInstanceId == permittedMasterInstanceId))
{
var masterInstance = new MasterInstance {MasterInstanceId = permittedMasterInstanceId};
context.MasterInstances.Attach(masterInstance);
installer.PermittedMasterInstances.Add(masterInstance);
}
}
// We're done - save and finish.
context.Entry<Installer>(installer).State = EntityState.Modified;
context.SaveChanges();
So this works... But, it seemed like a lot of effort, is this the right/best way to achieve it?
c# mvc entity-framework asp.net-mvc-3
$endgroup$
add a comment |
$begingroup$
I've got this all working, but it seems to be quite long-winded, and I thought I'd post here and see if I'm doing it wrong...
I have a M:M relationship between an Installer and a MasterInstance. The classes (code-first) look like:
public class MasterInstance
{
.. rest of fields here ..
public virtual ICollection<Installer> PermittedInstallers { get; set; }
}
public class Installer
{
.. rest of fields here ..
public virtual ICollection<MasterInstance> PermittedMasterInstances { get; set; }
}
I want to be able to edit these in my Installer view, using a multi-list box. So, I create a ViewModel for what I need:
public class InstallerViewModel
{
public Installer Installer { get; set; }
public List<MasterInstance> PermittedMasterInstances { get; set; }
public int SelectedMasterInstances { get; set; }
}
And then I place this in my view like so so that I can select the instances for my installer:
<div class="editor-field">
@Html.ListBoxFor(model => model.SelectedMasterInstances,(Model.PermittedMasterInstances).Select(option => new SelectListItem {
Text = option.Name,
Value = option.MasterInstanceId.ToString()
}))
</div>
In the controller, for the edit action, I need to set this view model up:
var installer = context.Installers.Include(i => i.PermittedMasterInstances).Single(x => x.InstallerId == installerId);
InstallerViewModel model = new InstallerViewModel
{
Installer = installer,
PermittedMasterInstances = context.MasterInstances.ToList(),
SelectedMasterInstances = installer.PermittedMasterInstances.Select(i => i.MasterInstanceId).ToArray()
};
return View(model);
Finally, on the post of the edit, I need to delete any relationships that are no longer there and add the new ones:
// Grab the model from the viewmodel and attach to the context
var installer = installerModel.Installer;
context.Installers.Attach(installer);
// Load the related records (dont know why Lazy Loading wouldn't kick in here)
context.Entry(installer).Collection(i => i.PermittedMasterInstances).Load();
// Iterate and delete existing relationships
var instancesToDelete = installer.PermittedMasterInstances.Where(mi => !installerModel.SelectedMasterInstances.Contains(i.MasterInstanceId)).ToList();
instancesToDelete.ForEach(mi => installer.PermittedMasterInstances.Remove(mi));
// Now loop through an int and add those new relations, WITHOUT the pain of fetching them from the DB
foreach (var permittedMasterInstanceId in installerModel.SelectedMasterInstances)
{
if (!installer.PermittedMasterInstances.Any(pmi => pmi.MasterInstanceId == permittedMasterInstanceId))
{
var masterInstance = new MasterInstance {MasterInstanceId = permittedMasterInstanceId};
context.MasterInstances.Attach(masterInstance);
installer.PermittedMasterInstances.Add(masterInstance);
}
}
// We're done - save and finish.
context.Entry<Installer>(installer).State = EntityState.Modified;
context.SaveChanges();
So this works... But, it seemed like a lot of effort, is this the right/best way to achieve it?
c# mvc entity-framework asp.net-mvc-3
$endgroup$
$begingroup$
This is exactly how ive approached this problem in the past, its a bit ugly but ive never fund a better way
$endgroup$
– Luke McGregor
Feb 15 '12 at 21:42
add a comment |
$begingroup$
I've got this all working, but it seems to be quite long-winded, and I thought I'd post here and see if I'm doing it wrong...
I have a M:M relationship between an Installer and a MasterInstance. The classes (code-first) look like:
public class MasterInstance
{
.. rest of fields here ..
public virtual ICollection<Installer> PermittedInstallers { get; set; }
}
public class Installer
{
.. rest of fields here ..
public virtual ICollection<MasterInstance> PermittedMasterInstances { get; set; }
}
I want to be able to edit these in my Installer view, using a multi-list box. So, I create a ViewModel for what I need:
public class InstallerViewModel
{
public Installer Installer { get; set; }
public List<MasterInstance> PermittedMasterInstances { get; set; }
public int SelectedMasterInstances { get; set; }
}
And then I place this in my view like so so that I can select the instances for my installer:
<div class="editor-field">
@Html.ListBoxFor(model => model.SelectedMasterInstances,(Model.PermittedMasterInstances).Select(option => new SelectListItem {
Text = option.Name,
Value = option.MasterInstanceId.ToString()
}))
</div>
In the controller, for the edit action, I need to set this view model up:
var installer = context.Installers.Include(i => i.PermittedMasterInstances).Single(x => x.InstallerId == installerId);
InstallerViewModel model = new InstallerViewModel
{
Installer = installer,
PermittedMasterInstances = context.MasterInstances.ToList(),
SelectedMasterInstances = installer.PermittedMasterInstances.Select(i => i.MasterInstanceId).ToArray()
};
return View(model);
Finally, on the post of the edit, I need to delete any relationships that are no longer there and add the new ones:
// Grab the model from the viewmodel and attach to the context
var installer = installerModel.Installer;
context.Installers.Attach(installer);
// Load the related records (dont know why Lazy Loading wouldn't kick in here)
context.Entry(installer).Collection(i => i.PermittedMasterInstances).Load();
// Iterate and delete existing relationships
var instancesToDelete = installer.PermittedMasterInstances.Where(mi => !installerModel.SelectedMasterInstances.Contains(i.MasterInstanceId)).ToList();
instancesToDelete.ForEach(mi => installer.PermittedMasterInstances.Remove(mi));
// Now loop through an int and add those new relations, WITHOUT the pain of fetching them from the DB
foreach (var permittedMasterInstanceId in installerModel.SelectedMasterInstances)
{
if (!installer.PermittedMasterInstances.Any(pmi => pmi.MasterInstanceId == permittedMasterInstanceId))
{
var masterInstance = new MasterInstance {MasterInstanceId = permittedMasterInstanceId};
context.MasterInstances.Attach(masterInstance);
installer.PermittedMasterInstances.Add(masterInstance);
}
}
// We're done - save and finish.
context.Entry<Installer>(installer).State = EntityState.Modified;
context.SaveChanges();
So this works... But, it seemed like a lot of effort, is this the right/best way to achieve it?
c# mvc entity-framework asp.net-mvc-3
$endgroup$
I've got this all working, but it seems to be quite long-winded, and I thought I'd post here and see if I'm doing it wrong...
I have a M:M relationship between an Installer and a MasterInstance. The classes (code-first) look like:
public class MasterInstance
{
.. rest of fields here ..
public virtual ICollection<Installer> PermittedInstallers { get; set; }
}
public class Installer
{
.. rest of fields here ..
public virtual ICollection<MasterInstance> PermittedMasterInstances { get; set; }
}
I want to be able to edit these in my Installer view, using a multi-list box. So, I create a ViewModel for what I need:
public class InstallerViewModel
{
public Installer Installer { get; set; }
public List<MasterInstance> PermittedMasterInstances { get; set; }
public int SelectedMasterInstances { get; set; }
}
And then I place this in my view like so so that I can select the instances for my installer:
<div class="editor-field">
@Html.ListBoxFor(model => model.SelectedMasterInstances,(Model.PermittedMasterInstances).Select(option => new SelectListItem {
Text = option.Name,
Value = option.MasterInstanceId.ToString()
}))
</div>
In the controller, for the edit action, I need to set this view model up:
var installer = context.Installers.Include(i => i.PermittedMasterInstances).Single(x => x.InstallerId == installerId);
InstallerViewModel model = new InstallerViewModel
{
Installer = installer,
PermittedMasterInstances = context.MasterInstances.ToList(),
SelectedMasterInstances = installer.PermittedMasterInstances.Select(i => i.MasterInstanceId).ToArray()
};
return View(model);
Finally, on the post of the edit, I need to delete any relationships that are no longer there and add the new ones:
// Grab the model from the viewmodel and attach to the context
var installer = installerModel.Installer;
context.Installers.Attach(installer);
// Load the related records (dont know why Lazy Loading wouldn't kick in here)
context.Entry(installer).Collection(i => i.PermittedMasterInstances).Load();
// Iterate and delete existing relationships
var instancesToDelete = installer.PermittedMasterInstances.Where(mi => !installerModel.SelectedMasterInstances.Contains(i.MasterInstanceId)).ToList();
instancesToDelete.ForEach(mi => installer.PermittedMasterInstances.Remove(mi));
// Now loop through an int and add those new relations, WITHOUT the pain of fetching them from the DB
foreach (var permittedMasterInstanceId in installerModel.SelectedMasterInstances)
{
if (!installer.PermittedMasterInstances.Any(pmi => pmi.MasterInstanceId == permittedMasterInstanceId))
{
var masterInstance = new MasterInstance {MasterInstanceId = permittedMasterInstanceId};
context.MasterInstances.Attach(masterInstance);
installer.PermittedMasterInstances.Add(masterInstance);
}
}
// We're done - save and finish.
context.Entry<Installer>(installer).State = EntityState.Modified;
context.SaveChanges();
So this works... But, it seemed like a lot of effort, is this the right/best way to achieve it?
c# mvc entity-framework asp.net-mvc-3
c# mvc entity-framework asp.net-mvc-3
edited Aug 1 '14 at 21:14
Jamal♦
30.4k11121227
30.4k11121227
asked Feb 1 '12 at 8:47
Matt RobertsMatt Roberts
1513
1513
$begingroup$
This is exactly how ive approached this problem in the past, its a bit ugly but ive never fund a better way
$endgroup$
– Luke McGregor
Feb 15 '12 at 21:42
add a comment |
$begingroup$
This is exactly how ive approached this problem in the past, its a bit ugly but ive never fund a better way
$endgroup$
– Luke McGregor
Feb 15 '12 at 21:42
$begingroup$
This is exactly how ive approached this problem in the past, its a bit ugly but ive never fund a better way
$endgroup$
– Luke McGregor
Feb 15 '12 at 21:42
$begingroup$
This is exactly how ive approached this problem in the past, its a bit ugly but ive never fund a better way
$endgroup$
– Luke McGregor
Feb 15 '12 at 21:42
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
I know this is an old question, but I think the problem is timeless. Many to many associations (i.e. without junction class) in Entity Framework are always independent associations, so you can only establish or remove them by manipulating object collections, not primitive key values. Inefficiency is inherent to the implementation.
But it is not prohibited to have a second context that only contains junction tables.
You could create a context that contains the MasterInstanceInstaller
junction table and use this to update the associations in the most efficient way you can get using EF:
var installer = installerModel.Installer;
var junctions = context.MasterInstanceInstallers
.Where(x => x.InstallerId == installer.InstallerId)
.ToList();
// Delete deselected instances.
foreach(var mi in junctions
.Where(x => !installerModel.SelectedMasterInstances
.Contains(x.MasterInstanceId)))
{
context.MasterInstanceInstallers.Remove(mi);
}
// Add newly selected instances.
foreach(int instanceId in installerModel.SelectedMasterInstances
.Except(junctions.Select(j => j.MasterInstanceId)))
}
context.MasterInstanceInstallers.Add(new MasterInstanceInstaller
{
InstallerId = installer.InstallerId,
MasterInstanceId = instanceId
}
);
}
context.SaveChanges();
Now, if necessary you can populate the updated many to many association through the main context.
$endgroup$
$begingroup$
+1 It's never too late to shoot a zombie!
$endgroup$
– Mathieu Guindon
Mar 27 '14 at 0:03
add a comment |
$begingroup$
It definitely is timeless. I've done it with and without the explicit junction table over the years but for the first time I find myself wanting the best of both worlds needing both:
- "mutual collections" approach
that is in effect by omitting the junction table in the model - Explicit junction table in model approach
Letting one grapple with joins
I'm currently considering using a view to avoid explicit inclusion of junction table in the model in order to let me do the joins I might sometimes need and to also shape the returned data with additional selection criteria in the ON clauses used to join each side of the many-to-many relationship. Will report back as to the success of failure of this approach.
New contributor
$endgroup$
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f8537%2fefficient-way-to-deal-with-maintaining-manymany-relationships-in-ef-code-first%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
I know this is an old question, but I think the problem is timeless. Many to many associations (i.e. without junction class) in Entity Framework are always independent associations, so you can only establish or remove them by manipulating object collections, not primitive key values. Inefficiency is inherent to the implementation.
But it is not prohibited to have a second context that only contains junction tables.
You could create a context that contains the MasterInstanceInstaller
junction table and use this to update the associations in the most efficient way you can get using EF:
var installer = installerModel.Installer;
var junctions = context.MasterInstanceInstallers
.Where(x => x.InstallerId == installer.InstallerId)
.ToList();
// Delete deselected instances.
foreach(var mi in junctions
.Where(x => !installerModel.SelectedMasterInstances
.Contains(x.MasterInstanceId)))
{
context.MasterInstanceInstallers.Remove(mi);
}
// Add newly selected instances.
foreach(int instanceId in installerModel.SelectedMasterInstances
.Except(junctions.Select(j => j.MasterInstanceId)))
}
context.MasterInstanceInstallers.Add(new MasterInstanceInstaller
{
InstallerId = installer.InstallerId,
MasterInstanceId = instanceId
}
);
}
context.SaveChanges();
Now, if necessary you can populate the updated many to many association through the main context.
$endgroup$
$begingroup$
+1 It's never too late to shoot a zombie!
$endgroup$
– Mathieu Guindon
Mar 27 '14 at 0:03
add a comment |
$begingroup$
I know this is an old question, but I think the problem is timeless. Many to many associations (i.e. without junction class) in Entity Framework are always independent associations, so you can only establish or remove them by manipulating object collections, not primitive key values. Inefficiency is inherent to the implementation.
But it is not prohibited to have a second context that only contains junction tables.
You could create a context that contains the MasterInstanceInstaller
junction table and use this to update the associations in the most efficient way you can get using EF:
var installer = installerModel.Installer;
var junctions = context.MasterInstanceInstallers
.Where(x => x.InstallerId == installer.InstallerId)
.ToList();
// Delete deselected instances.
foreach(var mi in junctions
.Where(x => !installerModel.SelectedMasterInstances
.Contains(x.MasterInstanceId)))
{
context.MasterInstanceInstallers.Remove(mi);
}
// Add newly selected instances.
foreach(int instanceId in installerModel.SelectedMasterInstances
.Except(junctions.Select(j => j.MasterInstanceId)))
}
context.MasterInstanceInstallers.Add(new MasterInstanceInstaller
{
InstallerId = installer.InstallerId,
MasterInstanceId = instanceId
}
);
}
context.SaveChanges();
Now, if necessary you can populate the updated many to many association through the main context.
$endgroup$
$begingroup$
+1 It's never too late to shoot a zombie!
$endgroup$
– Mathieu Guindon
Mar 27 '14 at 0:03
add a comment |
$begingroup$
I know this is an old question, but I think the problem is timeless. Many to many associations (i.e. without junction class) in Entity Framework are always independent associations, so you can only establish or remove them by manipulating object collections, not primitive key values. Inefficiency is inherent to the implementation.
But it is not prohibited to have a second context that only contains junction tables.
You could create a context that contains the MasterInstanceInstaller
junction table and use this to update the associations in the most efficient way you can get using EF:
var installer = installerModel.Installer;
var junctions = context.MasterInstanceInstallers
.Where(x => x.InstallerId == installer.InstallerId)
.ToList();
// Delete deselected instances.
foreach(var mi in junctions
.Where(x => !installerModel.SelectedMasterInstances
.Contains(x.MasterInstanceId)))
{
context.MasterInstanceInstallers.Remove(mi);
}
// Add newly selected instances.
foreach(int instanceId in installerModel.SelectedMasterInstances
.Except(junctions.Select(j => j.MasterInstanceId)))
}
context.MasterInstanceInstallers.Add(new MasterInstanceInstaller
{
InstallerId = installer.InstallerId,
MasterInstanceId = instanceId
}
);
}
context.SaveChanges();
Now, if necessary you can populate the updated many to many association through the main context.
$endgroup$
I know this is an old question, but I think the problem is timeless. Many to many associations (i.e. without junction class) in Entity Framework are always independent associations, so you can only establish or remove them by manipulating object collections, not primitive key values. Inefficiency is inherent to the implementation.
But it is not prohibited to have a second context that only contains junction tables.
You could create a context that contains the MasterInstanceInstaller
junction table and use this to update the associations in the most efficient way you can get using EF:
var installer = installerModel.Installer;
var junctions = context.MasterInstanceInstallers
.Where(x => x.InstallerId == installer.InstallerId)
.ToList();
// Delete deselected instances.
foreach(var mi in junctions
.Where(x => !installerModel.SelectedMasterInstances
.Contains(x.MasterInstanceId)))
{
context.MasterInstanceInstallers.Remove(mi);
}
// Add newly selected instances.
foreach(int instanceId in installerModel.SelectedMasterInstances
.Except(junctions.Select(j => j.MasterInstanceId)))
}
context.MasterInstanceInstallers.Add(new MasterInstanceInstaller
{
InstallerId = installer.InstallerId,
MasterInstanceId = instanceId
}
);
}
context.SaveChanges();
Now, if necessary you can populate the updated many to many association through the main context.
answered Mar 26 '14 at 21:17
Gert ArnoldGert Arnold
1,51111322
1,51111322
$begingroup$
+1 It's never too late to shoot a zombie!
$endgroup$
– Mathieu Guindon
Mar 27 '14 at 0:03
add a comment |
$begingroup$
+1 It's never too late to shoot a zombie!
$endgroup$
– Mathieu Guindon
Mar 27 '14 at 0:03
$begingroup$
+1 It's never too late to shoot a zombie!
$endgroup$
– Mathieu Guindon
Mar 27 '14 at 0:03
$begingroup$
+1 It's never too late to shoot a zombie!
$endgroup$
– Mathieu Guindon
Mar 27 '14 at 0:03
add a comment |
$begingroup$
It definitely is timeless. I've done it with and without the explicit junction table over the years but for the first time I find myself wanting the best of both worlds needing both:
- "mutual collections" approach
that is in effect by omitting the junction table in the model - Explicit junction table in model approach
Letting one grapple with joins
I'm currently considering using a view to avoid explicit inclusion of junction table in the model in order to let me do the joins I might sometimes need and to also shape the returned data with additional selection criteria in the ON clauses used to join each side of the many-to-many relationship. Will report back as to the success of failure of this approach.
New contributor
$endgroup$
add a comment |
$begingroup$
It definitely is timeless. I've done it with and without the explicit junction table over the years but for the first time I find myself wanting the best of both worlds needing both:
- "mutual collections" approach
that is in effect by omitting the junction table in the model - Explicit junction table in model approach
Letting one grapple with joins
I'm currently considering using a view to avoid explicit inclusion of junction table in the model in order to let me do the joins I might sometimes need and to also shape the returned data with additional selection criteria in the ON clauses used to join each side of the many-to-many relationship. Will report back as to the success of failure of this approach.
New contributor
$endgroup$
add a comment |
$begingroup$
It definitely is timeless. I've done it with and without the explicit junction table over the years but for the first time I find myself wanting the best of both worlds needing both:
- "mutual collections" approach
that is in effect by omitting the junction table in the model - Explicit junction table in model approach
Letting one grapple with joins
I'm currently considering using a view to avoid explicit inclusion of junction table in the model in order to let me do the joins I might sometimes need and to also shape the returned data with additional selection criteria in the ON clauses used to join each side of the many-to-many relationship. Will report back as to the success of failure of this approach.
New contributor
$endgroup$
It definitely is timeless. I've done it with and without the explicit junction table over the years but for the first time I find myself wanting the best of both worlds needing both:
- "mutual collections" approach
that is in effect by omitting the junction table in the model - Explicit junction table in model approach
Letting one grapple with joins
I'm currently considering using a view to avoid explicit inclusion of junction table in the model in order to let me do the joins I might sometimes need and to also shape the returned data with additional selection criteria in the ON clauses used to join each side of the many-to-many relationship. Will report back as to the success of failure of this approach.
New contributor
New contributor
answered 32 mins ago
Pat PattilloPat Pattillo
11
11
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f8537%2fefficient-way-to-deal-with-maintaining-manymany-relationships-in-ef-code-first%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
This is exactly how ive approached this problem in the past, its a bit ugly but ive never fund a better way
$endgroup$
– Luke McGregor
Feb 15 '12 at 21:42