Base solution for your next web application
Starts in:
01 DAYS
01 HRS
01 MIN
01 SEC
Open Closed

External POCO classes to Apb Entities. i.e. no inheritace possible #8126


User avatar
0
richardghubert created

Hi,

We have a pretty common situation and I'd like to understand the best-practice or trade-offs in AspNetZero to handle this best.

We import a package (NuGet) of pure C# classes (POCO). These are shared across several system. In our AspNetZero server, we want these to be first class persistent objects. However, they can't inherit from Entity, since they come from the Nuget. What is the best practice here?

My ideas to date (not being the expert here, of course):

  • If we were to use these classes as EF Navigation Properties in Apb Entities, i.e. always use them as complex-type properties of an Abp Entity class, it could do the trick. In this scenario, one would not even need to define a DbSet<POCO>, although one could (see: https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application )

  • Alternatively, if we just reference these complex types from an Apb Entity, doesn't EF generate Entity-Proxies for these and automatically make them into EF Navigation Properties (see: https://blogs.msdn.microsoft.com/adonet/2009/12/22/poco-proxies-part-1/ ) or is this not an option the default Abp flow. We'd like to avoid too much custom code (risk).

  • Any other way via delegation?

Thanks for any Tips/Example/Info!


6 Answer(s)
  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @richardghubert

    Are those classes derive from a specific class defined in the NuGet package you are using ?

  • User Avatar
    0
    richardghubert created

    Thanks,

    Actually it is our own set of POCOs that are C# classes based on https://github.com/protobuf-net/protobuf-net These POCOs must be shared across several systems and, as such, cannot depend on Abp/EF through inheritance.

    Best regards! Richard

  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @richardghubert

    Sorry for my late response. If thats the case, than I couldn't think any other alternative than your solutions. I was going to suggest you to create a structure like we did for Entity (generic repositories etc...) but in your case it seems like it is not possible.

  • User Avatar
    0
    richardghubert created

    Thanks, yes, this will save me some head-scratching time since I was still investigating code and documents to figure a way. So, correct me if I'm wrong: in the end, any Complex-Type that needs to be code-first (EF-Core) persistent must inherit from at compile time from the IEntity and be compiled into Abp to be "wired properly" for persistence. I'm still not sure why this is a do-or-die constraint, still ruminating on that!

  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @richardghubert

    No, it is not mandatory. You can just use regular EF Core stuff but you will not be able to use generic repositories of ABP. Otherwise, you can just use any POCO class in your DbContext and get them from database using custom repository, see https://aspnetboilerplate.com/Pages/Documents/Repositories#custom-repositories

  • User Avatar
    0
    ismcagdas created
    Support Team

    This issue is closed because it has not had recent activity for a long time.