Modeling a badly designed database using Entity Framework

I am trying to model a database that is badly designed. The POCO objects I came up using Entity F开发者_C百科ramework(EF) do not represent the business entities accurately as I am limited by bad DB design . I am planning on having my business entities defined separately and have them map to POCO. So it would be something like: Business Entities ==> POCO Entities ==> EF.

Do you see any disadvantages by doing this?

As such I am very new to EF and from what I have learned so far, it seems EF works best when the DB is perfect. Otherwise we end up with either customizing EDMX by hand or some other workarounds.

Thanks, Manav

How you handle this depends on where the hard work is in your application. You want to use an approach that maximizes the maintainability of your code.

If you have not too much transactional data capture (i.e. CRUD operations) and lots of complex business rules, then using an abtraction layer of POCOs will help to keep your complex business logic clean and manageable. If on the other hand, your business rules are nearly non-existent and your app is really just about capturing lots of records and storing them away in a database, then your abstraction layer becomes just more code to have to maintain.