Attribute constraints are the least of your problems. EF models are not POCO objects, they are DTO entities which are very tightly inter-twined with your database schema and your
There's a huge amount of invisible logic lurking behind those innocent looking
set properties; they (the DTO entities) do all kinds of magical 'EF' things, such as:
- Translate your LINQ-to-Entities queries into SQL
- Handle lazy loading
- EF models are also tied into the
EntityState for the
Unfortunately, a lot of getting-started ASP.NET MVC tutorials have you putting those models into your controllers. Those tutorials are teaching you a really bad habit which will bite you hard as soon as you try to do something non-trivial
For example, imagine you have an
Employee EF model, which also has a method in it called
See this bit of LINQ, looks innocent right?
var managers = from emp in MyDbContext.Employees
where emp.Department == "Sales"
MyDbContext.Employees were something simple like a
Employee is a regular POCO, this would be fine. but unfortunately the above query will throw an exception because it tries to convert
emp.GetManager() into a SQL statement - except there is no such thing as
GetManager in SQL...
Another issue - if you have any lazy-loaded properties which you attempt to use after
DbContext.Dispose(), you'll find yourself either needing to forcibly load the property before you dispose (and remember to set
EntityState.Detached too), or performing all of your business logic within your
Of course, that might be ok if you have very simple business logic which only cares about a few simple database entities; you need to keep perspective and remember that KISS is also important.
However, its reasonable to expect you might also need to grab some data from another source, like a file, a network service, another API or other database, etc. Business logic which happens inside an EF
using block is a common pathway to technical debt and hard-to-maintain code.
Of course, all of these are things which you can 'work around', but the result is likely to mean mixing all of your UI logic in with your business and data layer logic; separation of UI concerns versus Database concerns becomes awkward when you use EF models in a
So, be very careful when deciding to use EF models directly in your MVC Controllers because anything marginally non-trivial can see you fighting all kinds of exceptions thrown by EF which you wouldn't see in regular mapped POCO models. The price to pay for the nominal amount of extra boilerplate code which maps from your EF models to your 'Business Layer' models is very reasonable, compared with the awful technical debt which you can end up with otherwise.