If I am not concerned with unit testing and switching my data access out at a later time, would using my entity framework objects as my business objects be okay?
I have an existing database for which I generated entities and a datacontext, and have partial classes for holding my methods and any additional (non-database) properties. I have read quite a bit about repository pattern and other seemingly complex ways of setting this up, but I'm not sure all of that is necessary. It is a .NET Web Forms app using Entity Framework 6.1.3 and will not have unit testing.
Are there other reasons why I should avoid such a simplistic approach?
Best Answer
I don't think you should use them as business objects. According to Vaughn Vernon EF is too inflexible be used directly as business objects
Instead use them as state objects. That is wrap them with a better encapsulation of your business logic. In the link I provided he i talking about DDD. What you refer to as business objects are called aggregate roots in DDD but the point still stands.