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 think, that I understand the difference between Content Providers and Databases. I have two apps, that should share data between them, so I need to use Content Provider. Yet, the amount of boilerplate code in Content Providers makes me shiver.
I have used some ORM libs previously, such as SugarORM & Requery, that seriously simplify communication with SQLite DB.
Is there some commonly used libs to simplify Content Providers code in similar way?
Is there any use of ORM libs for implementing backing DB for Content Provider?
If there is, a link for such project, combing Content Providers with backing ORM DB will be really appreciated.
StorIO provides ORM-like functionality for an Android ContentProvider with very similar API and functionality as their SQLite library and with native RxJava support.
https://github.com/pushtorefresh/storio
Read about StorIOContentResolver at this link.
https://github.com/pushtorefresh/storio/blob/master/docs/StorIOContentResolver.md
I am developing one application in MVC4 with sybase as database. I am not using Enterprise library for database activity and not using any ORM tools like Entity Framework.
I want to implement Repository and Unit of work patern in this application for models. But on internet all application sample i found uses entity framework.
Please help me to achieve repository patern without entity framework.
Repository pattern is unrelated to ORM or the db you're using. You simply define an interface that works with your business objects (save/get) and implement it in DAL.
The Repository implementation will just use whatever you have to access the db (ado.net, a micro orm, full ORM), really it's just a class working with the db saving and restoring business objects. Nothing special, nothing magic.
I have some experience with NHibernate and I'm trying to get started with Castle Nhibernate Facilities OR Castle NhibernateIntegration. I'd like to know, where I can find a demonstration project of how to configure and perform transactional control (with attributes) in a service layer (business, class library project)? There is no documentation, and I have a really difficult to find some content to getting started.
I found some samples on the web but only with pieces of code and not the demonstration project... I would like to download something to study. I'm not finding to a complete solution, just the configuration and transactional control in business classes (class library).
Sorry for this kind of thread here, but I do know how to start.
Thank you!
If you want to see an full example of Castle Windsor integrating with nHibernate then I would check out Sharp Architecture
Sharp is an attempt at a 'best practice' template project and utilises a number of tech's (Castle and nHibernate included). While some of the things it does may not be to your taste it will clearly show you one of the ways that it can all fit together.
You may need to go hunting into the source repository on GitHub if you want to see what is going on at a low level as Sharp uses it's own base classes in the template project that are pre-compiled (tho its still open source so you can see what is going on if you want).
It was an invaluable help to me when I was putting my architecture together and I can honestly say that Castle and nHibernate are the way to go, so you are very much on the right track.
EDIT FOR COMMENT 1: Perhaps I am a little confused here. According to the Castle notes
Facilities are main way of extending the container. Using facilities
you can integrate container with external framework, like WCF or
NHibernate, add new capabilities to the container like event wiring,
transaction support... or to components (synchronization, startable
semantics...).
To the best of my knowledge both Castle Nhibernate Facilities and Castle NhibernateIntegration are Facilities and must be based on a container.
If you want to work without a container then you need to use some form of Singleton Factory to manage the SessionFactory. There is an example of this here.
In terms of attributes controlling Transactions then this is how Sharp does it (see here). You may get away with reusing this code and replacing NHibernateSession with your own Singleton like theirs.
You don't need to implement UnitOfWork as nHibernate is effectively doing this for you. What you really need is an architecture that allows you to manage a transaction at a single point of control (Singleton) and is available in every repository.
I'm writing an application that manages something like Drupal's nodes. I'm planning on using the app in various content management systems / applications (Concrete5, Wordpress, custom Zend & Yii applications, etc...).
Since I'm using it in so many different places, I have to package an ORM with the app (ie I can't use Conrete5's or Yii's ORM, etc...). I love Doctrine 2, but am concerned that this is too 'big' of an orm to be packaged with my app.
It get's messy, for example, if I'm incorporating this app with a Zend application which is running Doctrine 2. I don't want two 'instances' of Doctrine running in the same app. Is this a warranted concern?
Question: Is Doctrine 2 too 'big' for this project? If so, what would be a good alternative ORM?
If you are going to use your application as an extension for other CMSes and/or frameworks,you should definitley use an ORM for the following reasons which comes to my mind:
1.CMS database installations are different.some use mysql some use oracle ,etc and you will have to create your own adapters or
2.Use CMS's native database abstraction layers.So you will have to rerwite your own model for every cms plugin you are gonna make.
3.Doctrine can do many big jobs but using doctrine is rather easy.doctrine is not resources intensive.
4.using more than one instance of doctrine will not be a problem as far as i know.
5.however doctrine2 requires minimum installation of PHP 5.3 and some shared servers might have older versions of php which this problem will be resolved while time passes and 5.2 becomes obsolete.
However in some CMSes more than one connection will made for your extension to work.(one for the CMS'S native database queries and one for your doctrine query.)
Way 1: work with different ORM's via adapters
(+) better integration with frameworks
(-) a lot of work to implement adapters
(-) loss of flexibility (limited by your adapters interface)
Way 2 (my choice): Use PDO with FETCH_CLASS, it's comfortable enough (you can fetch data to instances of your classes). Most of modern ORM's on PHP works through PDO, so integration must be easy.
Also about Doctrine 2 & Yii -- I tested this combination, works fine.