I wrote a nice website using Abp 1.0. Since I was only focusing on it at the time, my solution has the usual layout:
SLN Application (IDomainService, IApplicationService) Core (Entity) EntityFramework (AbpDbContext, IRepository) Web Api
Now I have a new project - a Windows Service - that uses the same database. Hence, I could reuse Core and EntityFramework, however I don't need Abp for a Window Service. Therefore, the exact same entities and dbContext can't be shared.
Also, both Web and Windows Service have similar services but in the latter I don't have IDomainService/DomainService or IApplicationService.
I'd like to have neutral projects that implement Core without Entity, EntityFramework using the regular DbContext, my own Install code that registers with Castle Windsor and common Services that don't need to inherit from DomainService.
I know that sound like I should just dump Abp from the web, however Abp makes working with Angular really nice. I just want to include my neutral Core, EntityFramework and Service projects (and register them with Castle Windsor using plain Castle instead of Abp's wrappers) in the Web and also use them in my Windows Service.
I've read all the Abp documentation and still don't know how to do this.
5 Answer(s)
-
0
Hi,
If you want to use your regular classes in ABP, it will not be a problem. If you want to register them to ABP's dependency injection system, you can check this document <a class="postlink" href="https://aspnetboilerplate.com/Pages/Documents/Dependency-Injection#DocCustomRegistration">https://aspnetboilerplate.com/Pages/Doc ... gistration</a>.
You need to register them in your web project's Initialize method.
If your windows service is not going to use ABP, then you can use your classes any way you like. But ABP can be used in windows services and console apps as well, you can check this example if you want to use it in your windows service. <a class="postlink" href="https://github.com/aspnetboilerplate/aspnetboilerplate-samples/tree/master/AbpEfConsoleApp">https://github.com/aspnetboilerplate/as ... ConsoleApp</a>
Thanks.
-
0
Thank you for replying.
Regarding your statement "If you want to use your regular classes in ABP, it will not be a problem.", I swapped out my website's Entities (the ones that inherit from Abp's Entity) with my POCO entities (basically the same classes but keeping their primary key IDs in the class and not inheriting from anything.)
Now Application services that inject the entities (wrapped in an IRepository) are complaining. For example:
private readonly IRepository<User, long> userRepository; public UsersApplicationService ( IRepository<User, long> userRepo ) { userRepository = userRepo; }The error is:
The type 'MyProject.Core.User' cannot be used as a type parameter 'TEntity' in the generic type or method 'IRepository<TEntity, TPrimaryKey>'. There is no implicit reference conversion from 'MyProject.Core.User' to 'Abp.Domain.Entities.IEntity<long>'.
My classes that use a int instead of a long (e.g. IRepository<Company>) give a similar error. I thought maybe since Entity automatically adds 'Id' to each descendent, that adding 'Id' to my POCO would help but the error persists.
With respect to Dependency Injection, I think I get the concept and don't expect that to be a problem.
-
0
Hi,
If you want to use your entities with generic repositories, then you need to derive them from Entity class, otherwise it will not be possible.
Thanks.
-
0
The only other alternative to generic repositories is to create custom repositories that are still based on IRepository<TEntity, TPrimaryKey>.
Since I don't want ABP in my Windows Service, you are saying I'm out of luck trying to maintain centralized Core and EntityFramework projects and a shared Service project that holds a couple "Domain" services?
What did you mean initially by "If you want to use your regular classes in ABP, it will not be a problem"?
-
0
Hi,
What did you mean initially by "If you want to use your regular classes in ABP, it will not be a problem"? ReplyProbably I didn't understand your case very well at the beginning, that is why I wrote this.
