Does a Model in MVC Need To Be a Class Or is That Just a Common Pattern?
I realize I'm conflating / confusing two different topics, but it seems like in most popular MVC frameworks that I've come across the model is a class / object-oriented (and uses some sort of ORM or ODM that I might not want to use).
My question is: If I split my files into models, views, and controllers, but my model is simply a separate file that handles business logic, validates data and handles communication with a database... but I do it in my own way that isn't object-oriented... and maybe just uses super simplistic if statements for validation... is that still considered a model? Would that still be considered MVC?
Does the model need to be a class / object-oriented or is that just a super common pattern / preference?
Thanks!!
model-view-controller model
asked Nov 19 '18 at 18:16
BlueCodeBlueCode
275
add a comment |
I realize I'm conflating / confusing two different topics, but it seems like in most popular MVC frameworks that I've come across the model is a class / object-oriented (and uses some sort of ORM or ODM that I might not want to use).
My question is: If I split my files into models, views, and controllers, but my model is simply a separate file that handles business logic, validates data and handles communication with a database... but I do it in my own way that isn't object-oriented... and maybe just uses super simplistic if statements for validation... is that still considered a model? Would that still be considered MVC?
Does the model need to be a class / object-oriented or is that just a super common pattern / preference?
Thanks!!
model-view-controller model
asked Nov 19 '18 at 18:16
BlueCodeBlueCode
275
add a comment |
I realize I'm conflating / confusing two different topics, but it seems like in most popular MVC frameworks that I've come across the model is a class / object-oriented (and uses some sort of ORM or ODM that I might not want to use).
My question is: If I split my files into models, views, and controllers, but my model is simply a separate file that handles business logic, validates data and handles communication with a database... but I do it in my own way that isn't object-oriented... and maybe just uses super simplistic if statements for validation... is that still considered a model? Would that still be considered MVC?
Does the model need to be a class / object-oriented or is that just a super common pattern / preference?
Thanks!!
model-view-controller model
asked Nov 19 '18 at 18:16
BlueCodeBlueCode
275
I realize I'm conflating / confusing two different topics, but it seems like in most popular MVC frameworks that I've come across the model is a class / object-oriented (and uses some sort of ORM or ODM that I might not want to use).
My question is: If I split my files into models, views, and controllers, but my model is simply a separate file that handles business logic, validates data and handles communication with a database... but I do it in my own way that isn't object-oriented... and maybe just uses super simplistic if statements for validation... is that still considered a model? Would that still be considered MVC?
Does the model need to be a class / object-oriented or is that just a super common pattern / preference?
Thanks!!
model-view-controller model
model-view-controller model
asked Nov 19 '18 at 18:16
BlueCodeBlueCode
275
asked Nov 19 '18 at 18:16
BlueCodeBlueCode
275
asked Nov 19 '18 at 18:16
BlueCodeBlueCode
275
asked Nov 19 '18 at 18:16
BlueCodeBlueCode
275
asked Nov 19 '18 at 18:16
BlueCodeBlueCode
275
275
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
In general "Model" refers to your Business Object Model (BOM). If you subscribe to Domain Driven Design (DDD) then your Models in a Model View Controller (MVC) architecture will be representative of your BOMs as classes or interfaces. Those BOMs may also be your classes in an Object Relational Map architecture. Since it is better for an interface to be a description of what something can do and a class as a description of what something is, you would tend to see your Models represented as classes rather than interfaces. In terms of what "logic" is allowed inside of those model classes it is really up to you and your team. For example, while it is typical to put data validation in Models you may want to abstract those rules to a separate data validation class that your model uses. There is typically not a black and white rule about where business logic goes but it is generally considered best practice for each class to have a single responsibility based on the Single Responsibility Principle as part of the SOLID model. From my experience when I have called "Model" classes things that were not the Business Object Models, like a "RepositoryModel", it can be confusing about where the code representation of the data model was. Instead I recommend using the word "Model" to be reserved for things which end users are familiar with and avoid the word "Model" for things they cannot.
answered Nov 19 '18 at 18:39
Josh WoodcockJosh Woodcock
1,5851016
add a comment |
Your Answer
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: "1"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2fstackoverflow.com%2fquestions%2f53380478%2fdoes-a-model-in-mvc-need-to-be-a-class-or-is-that-just-a-common-pattern%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
In general "Model" refers to your Business Object Model (BOM). If you subscribe to Domain Driven Design (DDD) then your Models in a Model View Controller (MVC) architecture will be representative of your BOMs as classes or interfaces. Those BOMs may also be your classes in an Object Relational Map architecture. Since it is better for an interface to be a description of what something can do and a class as a description of what something is, you would tend to see your Models represented as classes rather than interfaces. In terms of what "logic" is allowed inside of those model classes it is really up to you and your team. For example, while it is typical to put data validation in Models you may want to abstract those rules to a separate data validation class that your model uses. There is typically not a black and white rule about where business logic goes but it is generally considered best practice for each class to have a single responsibility based on the Single Responsibility Principle as part of the SOLID model. From my experience when I have called "Model" classes things that were not the Business Object Models, like a "RepositoryModel", it can be confusing about where the code representation of the data model was. Instead I recommend using the word "Model" to be reserved for things which end users are familiar with and avoid the word "Model" for things they cannot.
answered Nov 19 '18 at 18:39
Josh WoodcockJosh Woodcock
1,5851016
add a comment |
In general "Model" refers to your Business Object Model (BOM). If you subscribe to Domain Driven Design (DDD) then your Models in a Model View Controller (MVC) architecture will be representative of your BOMs as classes or interfaces. Those BOMs may also be your classes in an Object Relational Map architecture. Since it is better for an interface to be a description of what something can do and a class as a description of what something is, you would tend to see your Models represented as classes rather than interfaces. In terms of what "logic" is allowed inside of those model classes it is really up to you and your team. For example, while it is typical to put data validation in Models you may want to abstract those rules to a separate data validation class that your model uses. There is typically not a black and white rule about where business logic goes but it is generally considered best practice for each class to have a single responsibility based on the Single Responsibility Principle as part of the SOLID model. From my experience when I have called "Model" classes things that were not the Business Object Models, like a "RepositoryModel", it can be confusing about where the code representation of the data model was. Instead I recommend using the word "Model" to be reserved for things which end users are familiar with and avoid the word "Model" for things they cannot.
answered Nov 19 '18 at 18:39
Josh WoodcockJosh Woodcock
1,5851016
add a comment |
In general "Model" refers to your Business Object Model (BOM). If you subscribe to Domain Driven Design (DDD) then your Models in a Model View Controller (MVC) architecture will be representative of your BOMs as classes or interfaces. Those BOMs may also be your classes in an Object Relational Map architecture. Since it is better for an interface to be a description of what something can do and a class as a description of what something is, you would tend to see your Models represented as classes rather than interfaces. In terms of what "logic" is allowed inside of those model classes it is really up to you and your team. For example, while it is typical to put data validation in Models you may want to abstract those rules to a separate data validation class that your model uses. There is typically not a black and white rule about where business logic goes but it is generally considered best practice for each class to have a single responsibility based on the Single Responsibility Principle as part of the SOLID model. From my experience when I have called "Model" classes things that were not the Business Object Models, like a "RepositoryModel", it can be confusing about where the code representation of the data model was. Instead I recommend using the word "Model" to be reserved for things which end users are familiar with and avoid the word "Model" for things they cannot.
answered Nov 19 '18 at 18:39
Josh WoodcockJosh Woodcock
1,5851016
In general "Model" refers to your Business Object Model (BOM). If you subscribe to Domain Driven Design (DDD) then your Models in a Model View Controller (MVC) architecture will be representative of your BOMs as classes or interfaces. Those BOMs may also be your classes in an Object Relational Map architecture. Since it is better for an interface to be a description of what something can do and a class as a description of what something is, you would tend to see your Models represented as classes rather than interfaces. In terms of what "logic" is allowed inside of those model classes it is really up to you and your team. For example, while it is typical to put data validation in Models you may want to abstract those rules to a separate data validation class that your model uses. There is typically not a black and white rule about where business logic goes but it is generally considered best practice for each class to have a single responsibility based on the Single Responsibility Principle as part of the SOLID model. From my experience when I have called "Model" classes things that were not the Business Object Models, like a "RepositoryModel", it can be confusing about where the code representation of the data model was. Instead I recommend using the word "Model" to be reserved for things which end users are familiar with and avoid the word "Model" for things they cannot.
answered Nov 19 '18 at 18:39
Josh WoodcockJosh Woodcock
1,5851016
answered Nov 19 '18 at 18:39
Josh WoodcockJosh Woodcock
1,5851016
answered Nov 19 '18 at 18:39
Josh WoodcockJosh Woodcock
1,5851016
answered Nov 19 '18 at 18:39
Josh WoodcockJosh Woodcock
1,5851016
1,5851016
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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.
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%2fstackoverflow.com%2fquestions%2f53380478%2fdoes-a-model-in-mvc-need-to-be-a-class-or-is-that-just-a-common-pattern%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
