ORM Entities vs. Domain Entities under Entity Framework 6.0 -

i stumbled upon following 2 articles first , second in author states in summary orm entities , domain entities shouldn't mixed up.

i face problem @ moment code ef 6.0 using code first approach. use poco classes entities in ef domain/business objects. find myself in situation define property public or navigation property virtual because ef framework forces me so.

i don't know take bottom line of 2 articles? should create example customeref class entity framework , customerd domain. create repository consumes customerd maps customeref queries , maps received customeref customerd. thought ef mapping domain entities data.

so please give me advice. overlook important thing ef able provide me with? or problem can not solved ef? in latter case way manage problem?

i agree general idea of these posts. orm class model part of data access layer first , foremost (even if consists of so-called pocos). if conflict of interests arises between persistence , business logic (or other concern), decisions should made in favor of persistence.

however, software developers have balance between purism , pragmatism. whether or not use persistence model domain model depends on number of factors:

• the size/coherence of development team. when whole team knows properties can public because of orm requirements, should not set on place, may not big deal. if knows (and obeys) id property not used in business logic, having ids may not big deal. scattered, unexperienced or undisciplined team may need more stringent segregation of code.

• the overlap between business logic concerns , persistence concerns. object oriented design thrives when class model sticks solid principles. these principles not @ odds persistence concerns. mean although concerns different, in end resultant requirements may quite similar. instance, both concerns may require valid object state , correct associations.

  there can use cases, however, in objects temporarily need in state absolutely shouldn't stored. may reason work dedicated domain classes. reason may entity model can't fulfill best segmentation of responsibilities. instance, business process "blacklisting customer" may require data scattered on many entity objects new domain classes must designed can encapsulate data , methods working on them. in other words: doing entities violate tell don't ask principle.

• the need layering. instance, if data access layer targets different database vendors may have consist of interchangeable parts vendor-specific (e.g. account subtle differences in data types between oracle , sql server or exploit vendor-specific features). using persistence model domain model bleed vendor-specific implementations business logic. bad. there data access layer should precisely that, layer.

• (very trivial) amount of data. creating objects takes time , resources. when "many" objects involved in business case may expensive build both entity objects , domain objects.

and more, undoubtedly.

so try pragmatist. if entity classes decent job, go it. if mismatch large, create business domain appropriate parts of business logic. not slavishly follow (any) design pattern because pattern. contrary said in post, requires lot of maintenance map entity model onto business model. when find creating myriads of business classes identical entity classes it's time rethink you're doing.