I recently stumbled upon ABP (previously Asp.Net BoilerPlate) as a framework to rebuild a web-app in a modular way. It's very interesting indeed, and come with a very wild bunch of basic elements like authentication, logging, security, multi-tenancy, settings and so on...
But, as far as I have understood it by now, ABP is "strongly coupled" with EF Core or Dapper, and I don't like to use ORM in my code, I have a more "database driven" approach and like to write queries myself.
So, the main question is: it's possible to use ABP WITHOUT using EFCore/Dapper? Or it's better to switch to other modular framework like OrchardCore or ExtCore?
EDIT: 11/11/2020 after #hikalkan reply.
Hi #hikalkan, thanks for your kind reply. Maybe I have to explain more what I want to achieve, so you can advise me better. My goal is to create a "pluggable" web-app, in which I can replace a module with another with same functionality but different details.
A little introduction: I have a "complex" web-app for HR departments of small-to-medium companies, many customers use it, and each one have its own copy installed in its premises. The app is composed by many functionality: personal data, contracts data, trainings data, shifts and so on. But each customer have slightly different modules, while the app itself is an old, monolithic one: it works, but I have to maintain different versions, almost one for each customer, very difficult and time consuming. Don't blame it on me, I have "inherited" the app and have to maintain and improve it that way.
But, finally, I can spend some time rebuild it from scratch, and I want it to be "modular", so that the main part (authentication, profiling, db interaction, theming, security, logging, etc...) stay stable & solid, shared among all installations, and each customer have a selection of module/plug-in to choose from. A bit like Wordpress, but better.
For example, let's say I have a simple module "contactSimple" for managing contacts (emails, phone numbers, pagers, and so on), each contact have a type and a value field in the database, very basic, and 90% of my customers are happy with it. But the remaining 10% want to add a note field, a flag "is main contact" or other minor changes. Now, what i want to do is: develop the "contactEnhanced" module as a separetad class library, with same interface and main functions of "contactSimple", compile it as a dll, simply change the dll in the web-app, update the database if needed to, reload the app and the new dll takes place, without altering any other component.
I was thinking to simply use dynamic reflection to obtain it, but then i found that reflection is not very suited, 'cause is slow and heavy on resources, so while surfing the web I find ABP.
Now, THE question: in your opinion, is ABP the framework/solution I was searching for? Please let me know!
ABP is designed to be database provider independent. It currently has two DB provider integration options: EF Core & MongoDB. That means ABP is not strongly coupled with the EF Core or Dapper: It works with MongoDB too. You set -d mongodb if you've created your solution with the ABP CLI.
So, the Framework itself has no relation to any database provider. But the pre-built modules have. For example, ABP provides an Identity module that has user and role management functions and needs to a database and includes some code to interact with the database. So it can't be db provider independent. All the pre-built modules provides EF Core & MongoDB integration packages.
If you want to use these modules (when you create a new application from the startup templates, some modules come pre-installed), you have to decide to use EF Core or MongoDB for the database operations of these modules.
When it comes to you own application code: You are free to use any approach, including ADO.NET with manual SQL queries. Just do it how you do in a regular application. If you want to isolate database queries, create your own repository classes. In this way, you don't see ORM in your code. But the modules still use EF Core or MongoDB.
Actually there a possibility to completely drop the EF Core references: Implement all the repositories needed by the pre-built modules yourself. Then they will work since they only depend on repository interfaces.
BTW; If you use OrchardCore, it uses YesSQL (Yes, YES SQL) as a core dependency and you can not change it because all the OrchardCore framework depends on it everywhere. Also, OrchardCore is UI dependent: It uses aspnet core MVC / Razor Pages UI while the ABP Framework is UI independent and provides 3 built-in options: Angular, MVC and Blazor.
Edit: After edit of the question
The story you've explained is one of the goals of the ABP Framework. ABP is highly modular and also extensible. We built all the modules to be extensible. For example, the module entity extension system allows you to add new properties to existing entities of a module (the module is used as a NuGet package) without touching its source code. You can override the server side logic of the module.
But modularity is hard in general. I mean the module also should be designed so extensible/replaceable. If you want to declare some interfaces for a module, so the module can be completely replaceable, you have a lot of restrictions. For example, you can not write SQL join queries to tables of that module (because the replacement module can use a different table structure).
However, if the customizations will be lighter, you can follow the ABP Framework's module design to make your module extensible/customizable. See https://docs.abp.io/en/abp/latest/Customizing-Application-Modules-Guide and https://docs.abp.io/en/commercial/latest/guides/customizing-modules (commercial docs will be moved to the open source side since they are available as open source now). BTW, ABP supports to load modules as dlls from a folder. It reads dlls and initializes modules on application initialization.
I can only explains what ABP offers. I can't make suggestion, unfortunately. Because a real life project is complex and I can't predict all the problems & requirements you will have in the future :)
I just found the DispatchProxy class and wondering if I should wrap my Repository and Service objects with them (the wrapping is done by factory).
Currently I use Middleware's and ActionFilter's for logging and authenticating but the proxy seems to be better because with them I should be able to create my code more plattform Independent (they are supported in dot.Net Standard).
Is there a big drawback between Middleware/ActionFilter vs. DispatchProxy?
Has anyone experience with the DispatchProxy class in professional environments?
Are they much slower because they use delegates?
Thank you for your efforts!
(here an article about the DispatcherProxy: https://dzone.com/articles/aspect-oriented-programming-in-c-using-dispatchpro)
There seems to be quite a bit of information regarding using NHibernate and WCF Web Services but I'm struggling to find a definitive guide on how to implement the two technologies together in a efficient, thread safe way.
Specifically I want to grab the ISession object and uses that to get and save data through my existing repositories. My Business Objects, Unit Tests and ASP.NET Web Application all use the NHibernate framework and it works just great (it's my first hobby project using an ORM). My big question is how to combine this great framework with WCF Web Services.
I've read that version 3.0 NHibernate has NHibernate.Context.WcfOperationSessionContext but I'm unsure of it's implementation (see this question). From what I understand, one option is to store the ISession object in the OperationContext?
Can anyone point me in the direction of a implementation example?
Many thanks.
Here is a post describing, in detail, all the steps for registering and using the WcfOperationSessionContext. It also includes instructions for using it with the agatha-rrsl project.
WCF and Nhibernate work together in Sharp Architecture project. You can have a look at their implementation
I'm looking at new architecture for my site and was wondering if pairing NHibernate with a web service core is a good idea. What I want to do is make my webservice the core of my business, from the site front ends to the utilties I write. I'm trying to make all of my UIs completely ignorant of anything but my service API's.
In a simple strawman experiement, I'm running into issues with Serialzing my Iesi ISets....this is causing me to rethink the strategy altogether.
I know I could just develop a core Library (dll) and reference that in each of my applications, but maintaining that dll's version over a minimum of 6 applications seems like it's going to cause me much pain.
With NHibernate, what are the pro's and con's of those two approaches?
I see no problem in using NHibernate and webservices together - I just don't think it's a good idea to send the entities themselves over "to the other side".
A better approach is to use a set of DTOs that are made for the service - then you won't be running into issues like that of serializing unknown types and such.
You can use a library like AutoMapper to do the mapping from the entities to the DTOs.
There's a lot of stuff written about this, some of it:
http://martinfowler.com/bliki/FirstLaw.html
http://ayende.com/Blog/archive/2009/05/14/the-stripper-pattern.aspx
http://elegantcode.com/2008/04/27/dtos-or-serialized-domain-entities/
DTOs vs Serializing Persisted Entities
As a side note for the service it self, you could design wise use an approach like Davy Brion describes here: http://davybrion.com/blog/2009/11/requestresponse-service-layer-series/
I don't know NHibernate, but want to remind you that you should be using WCF for new web service development, unless you are stuck in the past (.NET 2.0). Microsoft now considers ASMX web services to be "legacy technology", and you can imagine what that means.
I have an XBap system designed as a 3-layer application. The XBap client consumes the logic through a WCF Service using netTcpBinding.
For easy of databinding and to be able to re use data validation built-in my business objects, I choosed to reference the business objects library from the xBap client instead of generating proxies.
These objects implement no logic other than they own basic data validation. The real business logic is implemented inside my WCF service.
Now I'm facing a big challenge. I need to port the xBap to silverlight, so I need my silverlight app. to consume the same business logic (which is also used by a winforms LOB application).
Some problems that arise:
1) Can't reference the business objects library from the silverlight client application because it's compiled as a regular dll and not a silverlight one.
2) Can't compile it as a silverlight library because I'd loose lots of functionallity and obviously is not a good idea anyway. If in the future a new .net platform arises I have no warranties that the modified (silverlight) dll will work.
I had some hope when I discovered RIAServices. I read somewhere I could implement a service and use any kind of DAL. (I have a custom one) but I found no example showing how to put RIAServices on top of an existing business layer. It's worth to say that we don't use (and we are not planning to) LINQ. Every example I found started using RIAServices and writing the business logic from scratch using LINQ.
RIAServices generates databinding-ready client code, but I feel I would have to change the entire business layer and that would be really expensive.
So, the solution seems to be to keep using WCF, specially now that silverlight 3.0 supports a new binary binding, and to work with proxies instead of the actual business objects.
The problem is that those proxies don't include data validation, property change notification and change tracking, three aspects that my business clasess perform.
RIAServices resolves these and other aspects but it requieres to work with silverlight proyects. WCF (SVCUtil.exe) generates proxies but they are not 'complete' for our needs. So It seems I'll have to develop my own utility for generating those proxies taking a business object as input.
Before I start doing so, I wish to know if anyone has already faced this problem and was able to resolve it in a convinient and painless way.
Thanks in advance,
Gonzalo
Check this blog post and sample - Business Apps Example for Silverlight 3 RTM and .NET RIA Services July Update: Part 8: WCF Based Data Source.
It shows writing a DomainService using .NET RIA Services that exposes operations and a model to Silverlight client, and in turn works against a WCF service.
You shouldn't need to change your business logic. The DomainService as a layer would reuse that, and it would make sense if you can't expose your business logic/WCF services as-is to Silverlight clients ...
Hope that helps.