0

Usually we have multiple namespaces in application, for example support, news, membership, ...
I am using EF v5. It is generate POCO classes automatically.but these classes are in same namespace.
I want some POCO class in membership namespace and some class in support and ... then i define another partial classes an extend the generated POCO classes (add static method and ...).
Is it possible or i am wrong in place.

Note:In this approche i don't want using News class and NewsManager class for CRUD operations.

Meh Man
  • 463
  • 1
  • 6
  • 22

1 Answers1

0

I had created a question about how generated POCO models/classes should be used with the separation of concerns, and we realized that the best way is to create your custom models/classes instead using directly POCOs in your application.

see there: Dal (with Entity Framework) and Model layers into MVC

thus you can set any namespace or traits to your custom models/classes. The 'bad' is: you need to transpose the POCO data (received from EF) to your custom models/classes. (in the link above Tallmaris suggested AutoMapper to do this work, but I did it manually).

I know your question is about using POCO in your application, but customizing the auto-generated could affect the EF's bind or even lose your customization (of namespaces) when update EF binds. Truly I don't know if it's really dangerous, but I would do this separated for safety, organization and to keep it simple!

Community
  • 1
  • 1
Wagner Leonardi
  • 4,226
  • 2
  • 35
  • 41
  • Thanks @Wanger, but in my idea AutoWrapper is not RAD solution here. AutoWrapper is good suggestion in SOA architecture and DTO. What i want is define different namespace for some classes in DataModel (POCO generated classes). I want add some methods and calculated properties to partial POCO classes – Meh Man Oct 17 '13 at 09:25
  • But remember that POCO is (auto-generated) DTO, that's why I told you customizing it isn't keep that simple and that's why is not easy customize them, they're made to be DTO. If you create custom classes (with custom namespaces, methods...) for each POCO (you can do it by yourself without AutoMapper, it takes 5 min. per class) will be more like a POCO's extension than architecture change. Do you agree with me? – Wagner Leonardi Oct 18 '13 at 17:37
  • Dear Wanger, POCO is a DTO but with object oriented behavior. So in non SOA architecture, we don't need to have tow classes (in none complex scenario). 1- POCO generated class and 2-custom classes in right namespace (that they are similar in most properties). My emphasis is on preventing duplication. – Meh Man Oct 18 '13 at 21:54