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.
Related
Is there built-in way to access databases in Suave?
Suave is a web server library, so it doesn't come with a built-in way to access a database or anything like a sql abstraction.
An option if you're looking for a framework that does have a way to access data built in, Saturn is a fine choice. It's also used as the backend for SAFE-stack if you're interested in full-stack F#.
Under the covers it's relatively simple, the template just lays down a CLI that lets you scaffold out some code and do migrations. And Dapper gets used as your database access library. But it does at least put things together in a template so that you can see how to connect things.
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'm building an ASP .NET MVC 4 application. Now, when I deploy a new version of this site to my live environment, I don't want to lose data just because my column names got renamed or something similar.
I'm using Entity Framework 4 to store objects in the database. Now, I am aware that this framework can generate so-called change-scripts. However, I do not trust them. Am I just being over-causious, or do I have reason not to trust them?
I'm designing the models in an EDMX diagram which then generates the tables for me. This makes it complicated for me to generate proper changescripts, especially when I do not (for sure) know how things are mapped into the database in certain scenarios.
So how do I get around this? If you use the same things as I do, what is your way of preventing data-loss on deployment?
I figured out that I probably have to wait for Entity Framework 5.
It seems that such a feature is already planned.
I know there are plenty of threads on when you should/shouldn’t use ORM. But at my level of “expertise” I’m far from qualified to be able to tell whether or not my app would be better off with or without ORM. And I don’t want to wait till I’m proficient enough to figure out whether I should learn ORM or not.
So could you tell me whether or not most of today’s web service apps (and most of web apps in general) are being written using ORM?
PS - I'm learning WCF and Asp.Net Web forms
I guess a lot of webapps (yes, probably most of them) use some orm persistence layer these days, provided they use a relational database. That goes for java (hibernate, jpa), .net, Python, groovy/grails and Rails (ActiveRecord by default).
There are also more and more orm solutions appearing for non-relational data stores.
It certainly depends on the language and application framework you are using, if any.
I am developing a cocoa application that will be making heavy use of both web services and a standard dbms (most likely MySQL) and I am wondering if anyone has a good option for a database library or ORM solution they have used. CoreData is not an option due to the need to support a standard DBMS and to be able to modify the data outside of the normal application operation.
I have found a number of possible options from new open source libraries:
http://github.com/aptiva/activerecord/tree/master
To writing my own wrapper for the C MySQL api.
Any advice is welcome,
Thanks!
Paul
We faced a similar question when we first started work on Checkout, our solution was to code the entire app in Python, using PyObjC. Checkout 1 had an sqlite backend, Checkout 2 has a postgres backend.
There are a couple of really mature and powerful ORMs on the Pyton side, such as SQLObject, which is pretty simple to work with (we used it for Checkout 1.0) and SQLAlchemy, which is more powerful but a bit harder to wrap your brain around (we used it for Checkout 2.0).
One approach you could evaluate, is building the application in Objective-C, but writing the data model and database connectivity/adminstration code in Python. You can use PyObjC to create a plugin bundle from this code, that you then load into your app That's more or less the approach we took for Checkout Server, which uses a Foundation command-line tool to administer a postgres server and the databases in it, this CLI tool in turn loads in a Python plugin bundle that has all of the actual database code in it. End-users mostly interact with the database through a System Preferences pane, that has no clue what the database looks like, but instead uses the command-line tool to interact with it.
Loading a plugin is simple:
NSBundle *pluginBundle = [NSBundle bundleWithPath:pluginPath];
[pluginBundle load];
You will probably need to create .h files for the classes in your bundle that you want to have access to from your Obj-C code.
You might also want to check out the BaseTen framework. It is a Core Data-like framework (in fact, it can import Core Data models), but works with PostgreSQL (though not MySQL, as far as I know). It includes some very nice features such as schema discovery at run time. It also includes an NSArrayController subclass that automatically handles locking and synchronizing across multiple users, so you can continue to make use of Apples Key-value Binding in your UI.
I have personal experience with this particular problem. I even started down the road of writing my own wrapper for the C MySQL API.
The eventual conclusion was: Don't!
The solution that worked in my case was to communicate with the MySQL server via PHP. If you are familiar with web services, chances are that you know about PHP, so I don't won't go into loads of detail about that.
To read from the database:
The cocoa app sends a request for a URL on the server: http://theserver.com/app/get_values.php
The get_values.php script handles the database query, and returns the data in xml format
The cocoa app loads and parses the xml
To write to the database:
The cocoa app sends a more complex request to the server: http://theserver.com/app/put_values.php?name="john doe"&age=21&address=...
The put_values.php script parses the input and writes to the database
The beauty of this solution is that PHP is great for working with MySQL, and cocoa has some handy built-in classes for working with XML data.
edit: one more thing:
One of the key things you have to figure out with this approach is how much processing should be done on the server, and how much should be done in the app itself. Let cocoa do the things that cocoa is good at, and let PHP and MySQL do the things that they are good at.
You could write a generic PHP script to handle all queries: perform_query.php?querystring="SELECT * FROM .....", but that is hardly an optimal solution. Your best bet is several smaller PHP scripts that handle individual datasets for you. In my case, there was one to get the list of users, one to get the list of transactions, etc. Again, it all depends on what your app is going to do.
GDL2 is a nice example, based on EOF.
Instead of reinventing the wheel by writing your own communication wrapper to deal with MySQL from Cocoa, you could try the SMySQL framework (a.k.a. MCPKit), it was part of the CocoaMySQL application that evolved into the Sequel Pro project. It works with varying versions of MySQL, and seems to be quite robust.
If you need to understand how to incorporate it into your application, there's not much documentation around, but it has an easy to understand interface and you can see it working by looking at the source of Sequel Pro, which is downloadable from Google code.
There is also the CocoaMySQL-SBG fork of the CocoaMySQL project, but that seems to be out of date and I couldn't get it to build properly.
I've also implemented a simple object persistence framework based on sqlite, but it certainly wasn't trivial to do. I agree with eJames' conclusion- don't implement one yourself if you don't have to.
If you aren't committed to programming in Objective-C you might want to take a look at PyObjC which would allow you to program the database portion in Python. You can use the MySQLdb module for DB access and there are plenty of tutorials online for its use. It isn't hard to stuff the data back into Cocoa/CF classes and pass them back to your app.
The main caveat with PyObjC is that at the moment it doesn't work with Tiger.