what is difference between a Model and an Entity - entity-framework

I am confused to understand what is the meaning of this words:
Entity, Model, DataModel, ViewModel
Can any body help me to understanding them please? Thank you all.

The definition of these terms is quite ambiguous. You will find different definitions at different places.
Entity: An entity represents a single instance of your domain object saved into the database as a record. It has some attributes that we represent as columns in our tables.
Model: A model typically represents a real world object that is related to the problem or domain space. In programming, we create classes to represent objects. These classes, known as models, have some properties and methods (defining objects behavior).
ViewModel: The term ViewModel originates from the MVVM (Model View ViewModel) design pattern. There are instances in which the data to be rendered by the view comes from two different objects. In such scenarios, we create a model class which consists of all properties required by the view. It’s not a domain model but a ViewModel because, a specific view uses it. Also, it doesn’t represent a real world object.
DataModel: In order to solve a problem, objects interact with each other. Some objects share a relationship among them and consequently, form a data model that represents the objects and the relationship between them.
In an application managing customer orders, for instance, if we have a customer and order object then these objects share a many to many relationship between them. The data model is eventually dependent on the way our objects interact with each other. In a database, we see the data model as a network of tables referring to some other tables.
To know more about object relationships visit my blog post: Basics of Object Relationships
For more details visit my blog post: Entity vs Model vs ViewModel vs DataModel

I hope I've not missed your point here king.net...
Anyway, presuming you're talking about entity modelling or entity-relationship modelling (ERDs):
an entity represents any real world entity - e.g. student, course,
an entity will have attributes - e.g. student has first name, surname, date-of-birth
an entity will have relationships - e.g. student "is enrolled on" course (where student and course are entities with attributes and "is enrolled on" is the relationship.
the relationship may be "one-to-one", "one-to-many" or "many-to-many" - e.g. one student "is enrolled on" many courses and similarly one course "has" many students.
relationships also have cardinality
Adding relationships between entities creates a "data model". You've modeled some real world system and the internal entities/ objects in that system. Next step is to normalise it to ensure it meets "normal form".
In ERD terms, you may have "logical" and "physical" models. The logical describes the data-model in simple high-level terms that witholds the technical detail required to implement it. It represents the system solution overview. The physical model includes technical details required to actually implement the system (such as "many-to-many join tables" needed to implement "many-to-many" relationships).
Here are some tutorials on-line (though I'm sure there must be thousands):
http://www.maakal.com/maakalDB/Database101ERDpart1.htm
http://www.itteam-direct.com/gwentrel.htm
http://www.bkent.net/Doc/simple5.htm
I'm not quite sure what you mean by "model" and "view model" in a related context. Not sure if you may be confusing this with Model-View-Controller paradigm (MVC). Here, a model is some data component and the view represents an observer of that data (such as a table or graph UI component). There's lots on-line explaining "model view controller" or "MVC".
Hope this helps, Wayne

Entity:
An entity is the representation of a real-world element within Object Relational Mapping (ORM) as the Entity Framework. This representation will be mapped to a table in a database and its attributes will be transformed into columns. An entity is written using a POCO class that is a simple class, as you can see in the following example in C#:
using System;
using System.Collections.Generic;
using System.Text;
namespace MyAplication.Entity
{
public class Person
{
public long PersonId { get; set; }
public string Name { get; set; }
public short Age { get; set; }
}
}
Working with UI creation is a complex task. To keep things organized, programmers separate their applications into layers.
Each layer is responsible for a task and this prevents the code from being messed up. It is in this scenario that the architectural patterns like the MVC and the MVVM appear.
Model:
Within the MVC we have a layer responsible for representing the data previously stored, a given could be an instance of a person modeled in the previous example. This layer is the Model. This template will be used to construct the view.
ViewModel:
A ViewModel in the MVVM architecture is much like a Model in the MVC architecture. However a ViewModel is a simplified representation of the data with only the information that is required for the construction of a view.
using System;
using System.Collections.Generic;
using System.Text;
using MyAplication.Web.ViewModel.BaseViewModel;
namespace MyAplication.Web.ViewModel.Person
{
public class PersonNameViewModel : BaseViewModel<string>
{
//I just neet the name
public string Name { get; set; }
}
}
DataModel:
It is simply an abstract model (this model is different from the MVC layer model) which establishes the relationships that exist between the elements that represent real-world entities. It is a very comprehensive subject.

First of all,to know about Entity you must know about Class.
All of them represent same fields but the terminology changes based on declaration.
Let us consider a table from any database[SQL,ORACLE,Informix,Cassandra..] as example.
CLASS:
Generally a table is a considered as a class until it is added to edmx or dbmx.
//Student class
public class Student()
{
//Properties
public int StudentNumber;
public string StudentName;
}
ENTITY:
After drag drop/adding the table into dbmx/edmx it is referred to as
Entity.
Each Entity is generated from its corresponding class and we can add
attributes to entity which are used for performing operations using
linq or entity.
DATAMODEL:
Contains all the fields in table.
DATAMODEL is a direct class reference to your cshtml or controller
where you can access the attributes to perform CRUD operations.
VIEWMODEL:
Some situations occur where we need to perform CRUD operations more
than one model(table).
So we combine all our required models in a class and define them in
its constructor.
Example:
Lets assume
//Student class
public class Student()
{
//Properties
public int StudentNumber;
public string StudentName;
}
//Marks Class
Public class Marks()
{
public int Maths;
public int Physics;
public int Chemistry;
//Now sometimes situations occur where we have to use one datamodel inside //other datamodel.
public Student StudentModel;
}

Simple talk:
DTO stands for Data Transfer Object. DTOs are mainly used for transferring data between services (web services, APIs, etc.) which can encompass variety of properties of different entities (with or without their ID). Take this row as an example of a DTO: Consider that a shopping website is going to send its shipping requests to a shipping company by a web-service. Its DTO would be something like this: CustomerFullName, ShippingFee, ShippingAddress. In this example CustomerFullName is combination of properties FirstName + LastName for the Customer entity, and ShippingFee is the result of several processes of destination, tax, etc over some other entities.
On the contrary, Entities are bunch of properties gathered to represent a single entity with a specific ID (e.g., Teacher, Student, Employee, etc.). In other words, DTOs are a bunch of meaningless properties gathered to be sent to the client and a DTO doesn't necessarily have relationship to the other DTOs, while an Entity includes properties of a specific object with meaningful relation to the other entities. In a relational database paradigm, we can look at DTOs as views' row while Entities are tables' row with the primary key.
However, Model is a combination of these two. A model can contain several related entities plus extra data to handle real-world application/UI problems. Consider a Model named CustomerOrdersModel that contains Customer Entity, List<Order> Entities, and an extra Boolean flag PayWithCredit specifying whether user is going to pay with debit-card or credit-card.

Related

What is the best apporach to create a Model class from DB table

I am trying to use a table suppose Account table from database containing 20 around columns and for different views I have requirement of different columns like for basic entries I need 10 columns for data insertion from one department and 5,5 from other departments. So, there will be 3 views who requires data or communicate between that table via Model So what will be the best approach to use:
1) Create 3 models like one contains only 10 columns and other 5-5?
2) Using only single model containing all columns. Isn't it gonna be carrying unnecessary data?
I know we can break that table and use relations to normalize data but I just want to understand more about the best approach like login Model and User Model. We can manage both with single model because we need username and password field for both but is it right way to use single model instead of 2?
The Model and ViewModel represent separate concerns. Keep them separate. The entity should reflect the data state, where you can define view models to support the different view concerns. When you go to load the view models from the EF context via the Entities, you utilize .Select() which will compose efficient SQL queries for just the columns your view model will need.
For example, if I have an Account entity with 20-odd properties defined, but I want to present a list of Accounts listing just their User Names, last login time, and list of roles: (Which would be the "Name" property of a Role referenced by a AccountRoles table linking a many-to-many between accounts and roles)
[Serializable]
public class AccountSummaryViewModel
{
public string AccountName { get; set; }
public DateTime LastLoginDateTime { get; set; }
public ICollection<string> Roles { get; set; } = new List<string>();
}
var accounts = MyContext.Accounts
.Where(x => x.IsActive)
.OrderBy(x => x.AccountName)
.Select(x => new AccountSummaryViewModel
{
AccountName = x.AccountName,
LastLoginDateTime = x.LastLoginDateTime,
Roles = x.Roles.Select(x => x.Role.Name).ToList()
}).ToList();
The entity structure reflects your data structure, but then when the server go to query those entities to serve a view, define the ViewModel for the data structure you want to display and leverage EF to compose a query to fill that view model.
You can also leverage Automapper for this with it's .ProjectTo<T>() method which integrates with EF's IQueryable implementation.
EF DbContexts can also only have one entity registered that is associated to a single table. To have multiple flavors of entity pointing at an Account table, you would need multiple DbContext definitions. Bounded contexts are useful for large systems, but can lead to miserably intertwined context references if used improperly.
It is advisable to avoid ever passing entities to a view because this can lead to all kinds of performance issues, exceptions, as well as security vulnerabilities, especially if controllers actions accept entities back from the client. By passing entities to a client The service is passing more information to the client than it needs, and you run into potential issues around triggering lazy loading calls, or tripping up the serialization with circular references. The system also tell hackers/competitors more about your data structure and data than it really should be. The UI may not display most of the information in the entity, but it is sending all of that data to the client. This requires more memory on the server/client, and larger payloads over the wire as well.

ViewModel Redundancy Clarification

I was recently reading about ViewModel and its advantages. I am able to understand why it is needed, however the question I have is If i have two classes for the same object(ie. Person class), doesn't i make the code redundant ? Also does it no make future changes a little difficult since you need to make sure the base class model and view model has the same number of properties is that right ? For instance let's say I have table called Person which has
ID
Name
Color
I am creating a hbm for creating the mapping for NHibernate. I have the following model class
public class Person {
public int ID {get;set;}
public string Name {get;set;}
public string color {get;set;} }
If i am correct, the view model class should look like
public class PersonViewModel {
[DisplayName("Full Name")]
public string Name {get;set;}
[DisplayName("Favourite Color")]
public string color {get;set;}
}
First, I have two classess referring to the same object in the db. Even though one class is used for DB purposes and other one is used for View purposes, we still have two class with exactly the same meta data. Secondly, If I introduce a new field in the db, I would need to add it in three places, Base Model class, View Model Class and the HBM file.
Please correct me if I am wrong, how can this be termed as code optimization or a best practice.
It depends on the approach you wish to take, you could expose the model directly as a property of your view model to avoid violating the DRY principle. However, this would violate the Law of Demeter so you would have to balance this, as your views would now be more tightly coupled with your domain model.
Also, in terms of validation, if you expose the model directly then you need to be careful that any property exposed could be set by an end user, even if you don't use the property directly in your view. You are also more likely to have different validation requirements per view, in which case validation would be the concern of the view model.
That's why the general best practice is not to expose your domain models directly to the view. You can use frameworks such as AutoMapper to reduce the data transfer plumbing code between the layers.

Building business logic on top of entity framework 5 POCOs

I've got an ADO.NET background and its the first time I've used Entity Framework in a serious project so I've gone ahead and got VS2012 and am using .NET 4.5 and entity framework 5.
I'm taking the data first approach and have created the database, generated the .edmx and also seperated out the POCOS from the context using this method: http://allen-conway-dotnet.blogspot.co.uk/2013/01/separating-entity-framework-poco.html
So my solution looks like this:
Data.Access (where I access the EF context and return POCOS to Business Layer)
Data.Model (where the POCOs are)
Data.Repository (where the context sites)
Presentation.Admin.Website
Now say I have the following table in the database / POCO class (just an example - not real)
namespace Data.Model
{
using System;
using System.Collections.Generic;
public partial class Car
{
public Car()
{
this.Parts= new HashSet<Parts>();
}
public int ID { get; set; }
public string Manufacturer { get; set; }
public string Model{ get; set; }
public Nullable<bool> Enabled { get; set; }
public virtual ICollection<Parts> Parts{ get; set; }
}
}
Now say all the cars in the database have an web service or even just a link to a URL which returns XML and gives me a list of available parts. The way in which each car retrieves the parts data is different (some are REST, some WCF, some from a CSV file, etc).
So I want to define classes that extend Car and define a "GetParts()" method which will have specific business logic to get parts for that particular car.
I also want to be able to get all cars from the database and loop them, calling the GetParts method for each one to retrieve the data.
I am thinking I need to define an interface or abstract class ICar declaring the GetParts method and somehow incorporating the Car POCO but getting confused about how to go about coding this.
Can anyone explain briefly how I can structure my code to get this done, perhaps suggesting a design pattern?
I'm taking the data first approach
The way in which each car retrieves the parts data is different (some
are REST, some WCF, some from a CSV file, etc).
Considering your type of data store is variable and you presumably want a reusable model then I think the choice of using EF database first is not a good one for you. Better to go with code first.
So I want to define classes that extend Car and define a "GetParts()"
method which will have specific business logic to get parts for that
particular car.
Your model should be persistence ignorant. I would not consider extending or hardcoding a data store specific GetParts() if that's what you are after.
perhaps suggesting a design pattern?
Perhaps look into using a repository to provide a layer of abstraction over your data mapping.

EF 4.2 Code First and DDD Design Concerns

I have several concerns when trying to do DDD development with EF 4.2 (or EF 4.1) code first. I've done some extensive research but haven't come up with concrete answers for my specific concerns. Here are my concerns:
The domain cannot know about the persistence layer, or in other words the domain is completely separate from EF. However, to persist data to the database each entity must be attached to or added to the EF context. I know you are supposed to use factories to create instances of the aggregate roots so the factory could potentially register the created entity with the EF context. This appears to violate DDD rules since the factory is part of the domain and not part of the persistence layer. How should I go about creating and registering entities so that they correctly persist to the database when needed to?
Should an aggregate entity be the one to create it's child entities? What I mean is, if I have an Organization and that Organization has a collection of Employee entities, should Organization have a method such as CreateEmployee or AddEmployee? If not where does creating an Employee entity come in keeping in mind that the Organization aggregate root 'owns' every Employee entity.
When working with EF code first, the IDs (in the form of identity columns in the database) of each entity are automatically handled and should generally never be changed by user code. Since DDD states that the domain is separate from persistence ignorance it seems like exposing the IDs is an odd thing to do in the domain because this implies that the domain should handle assigning unique IDs to newly created entities. Should I be concerned about exposing the ID properties of entities?
I realize these are kind of open ended design questions, but I am trying to do my best to stick to DDD design patterns while using EF as my persistence layer.
Thanks in advance!
On 1: I'm not all that familiar with EF but using the code-first/convention based mapping approach, I'd assume it's not too hard to map POCOs with getters and setters (even keeping that "DbContext with DbSet properties" class in another project shouldn't be that hard). I would not consider the POCOs to be the Aggregate Root. Rather they represent "the state inside an aggregate you want to persist". An example below:
// This is what gets persisted
public class TrainStationState {
public Guid Id { get; set; }
public string FullName { get; set; }
public double Latitude { get; set; }
public double Longitude { get; set; }
// ... more state here
}
// This is what you work with
public class TrainStation : IExpose<TrainStationState> {
TrainStationState _state;
public TrainStation(TrainStationState state) {
_state = state;
//You can also copy into member variables
//the state that's required to make this
//object work (think memento pattern).
//Alternatively you could have a parameter-less
//constructor and an explicit method
//to restore/install state.
}
TrainStationState IExpose.GetState() {
return _state;
//Again, nothing stopping you from
//assembling this "state object"
//manually.
}
public void IncludeInRoute(TrainRoute route) {
route.AddStation(_state.Id, _state.Latitude, _state.Longitude);
}
}
Now, with regard to aggregate life-cycle, there are two main scenario's:
Creating a new aggregate: You could use a factory, factory method, builder, constructor, ... whatever fits your needs. When you need to persist the aggregate, query for its state and persist it (typically this code doesn't reside inside your domain and is pretty generic).
Retrieving an existing aggregate: You could use a repository, a dao, ... whatever fits your needs. It's important to understand that what you are retrieving from persistent storage is a state POCO, which you need to inject into a pristine aggregate (or use it to populate it's private members). This all happens behind the repository/DAO facade. Don't muddle your call-sites with this generic behavior.
On 2: Several things come to mind. Here's a list:
Aggregate Roots are consistency boundaries. What consistency requirements do you see between an Organization and an Employee?
Organization COULD act as a factory of Employee, without mutating the state of Organization.
"Ownership" is not what aggregates are about.
Aggregate Roots generally have methods that create entities within the aggregate. This makes sense because the roots are responsible for enforcing consistency within the aggregate.
On 3: Assign identifiers from the outside, get over it, move on. That does not imply exposing them, though (only in the state POCO).
The main problem with EF-DDD compatibility seems to be how to persist private properties. The solution proposed by Yves seems to be a workaround for the lack of EF power in some cases. For example, you can't really do DDD with Fluent API which requires the state properties to be public.
I've found only mapping with .edmx files allows you to leave Domain Entities pure. It doesn't enforce you to make things publc or add any EF-dependent attributes.
Entities should always be created by some aggregate root. See a great post of Udi Dahan: http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/
Always loading some aggregate and creating entities from there also solves a problem of attaching an entity to EF context. You don't need to attach anything manually in that case. It will get attached automatically because aggregate loaded from the repository is already attached and has a reference to a new entity. While repository interface belongs to the domain, repository implementation belongs to the infrastructure and is aware of EF, contexts, attaching etc.
I tend to treat autogenerated IDs as an implementation detail of the persistent store, that has to be considered by the domain entity but shouldn't be exposed. So I have a private ID property that is mapped to autogenerated column and some another, public ID which is meaningful for the Domain, like Identity Card ID or Passport Number for a Person class. If there is no such meaningful data then I use Guid type which has a great feature of creating (almost) unique identifiers without a need for database calls.
So in this pattern I use those Guid/MeaningfulID to load aggregates from a repository while autogenerated IDs are used internally by database to make a bit faster joins (Guid is not good for that).

how to load associated entities at server side for MS Entity frame work?

Suppose I have a couple of table:
person(personid, name, email)
employee(personid,cardno, departmentID) //personid,departmentID is foreign key
department(departmentID, departmentName)
employeePhone(personID, phoneID) //this is relationship table
phone(phoneID, phonenumer)
When EntityFramework generate entity class for employee, this class have members like:
public partial class employee{
int _personid;
string _cardno;
string _departmentName;
person _person;
department _department;
//......
}
by default, when this class is loaded, only data available for employee table column, not data for associated entities data loaded.
If I use Linq to get the data at client side, Include should be used for linq query.
My question is: I want to the associated entities data loaded at server side when the employee is instantiated at server side. So when I get the entity at client side, all data available already so that I can easy to bind it to UI.
How to implement this request?
Don't bind entity types to your UI. This couples the UI to the entity layer. Loading will be the least of your problems. With a coupled UI, you violate the single responsibility principle, require blacklists/whitelists to be maintained to have any form of security, break types which can't deal with circular references, you have poor performance because you load all fields from all related types, etc., etc., etc.
Instead, create a dedicated view model and project onto it:
var pm = (from e in Context.Employees
where e.Id == id
select new EmployeePresentation
{
EmployeeNumber = e.Number,
Name = e.Person.Name,
// etc.
}.First();
Because this is LINQ to Entities, the fields you reference in Person, etc., are automatically loaded, without requiring eager loading, lazy loading, or explicit Load(). But only those fields, not the entirety of Person, as with every other method.
Update, per comments
Using presentation models is also important for updates. It is not the case that I want a user to be able to update every field that they can see. Different presentation models for the same entity might have different validation/scaffolding rules since they're used at different points in data flow within the app. Also, the user should implicitly update fields they cannot see (e.g., timestamp).
Generically, my updates look like this (ASP.MVC Web app):
public ActionResult Update(EmployeePresentation model)
{
if (!ModelState.IsValid)
{
// User violated validation rule on presentation model.
return View(model);
}
Repository.Update(model.Id, delegate(Employee employee)
{
model.UpdateEmployee(employee);
});
return RedirectToAction("Index");
}
Note that there is no possibility of the user ever updating something they're not allowed to, in a typechecked, type-safe way, and that the model binding, the presentation model and the repository can all be extended for custom behavior.
What you are hoping for is Lazy loading of the dependent Entities. There is an article located at the link below that talks about this and at the bottom of the article it also give you an explanation of how to perform a lazy load should you still feel the need.
See "Configuring Lazy Loading in Entity Framework" in this article:
Entity Framework and Lazy Loading