0

So I am thinking of using LLBLGen Pro and Spring.Net on this asp.net project using a service layer to decouple the Business Logic from the Data Store. I am also considering using PONOS in the UI Layer, now my question is:

Should I Map the rich LLBLGen Entity Objects to Ponos in the Data Layer or in the Service Layer? If I do it in the Data Layer then I loose all their rich functionality in the service layer. Or should I just skip the mapping to Ponos and use LLBLGen entities all the way through? If the later it will be harder to test it right?

Can someone give me pros and cons of both approaches?

Thanks

Luis
  • 5,979
  • 2
  • 31
  • 51

1 Answers1

3

The upside of using LLBLGen Entities with no mapping is that you get entities generated right from your database schema (or even with no database schema in LLBL 3.x), so you can have a very usable entity model in a matter of minutes. The downside is that your entities inherit from LLBL framework classes, which makes them harder to enrich with behavior/business logic. If you generally design your biz logic as a set of services, this won't pose a problem.

I don't see testing as a problem in this scenario, as I generally view the entities as "anemic" data objects, and I generally don't mock such objects (no real reason to do so).

The upside of mapping to POCOs is that you have full control over the design of your domain/entity/DTO objects, and they can be as rich or as anemic as you want. The downside is that you will have to design and code the POCO classes and the mapping, and (as you said) you will lose some functionality like change tracking that is built into LLBL Entities.

I personally choose to use the generated entity objects unless I have a very good reason NOT to.

Phil Sandler
  • 27,544
  • 21
  • 86
  • 147