I'm looking at building a quick administrative backend that services several databases. The databases are not connected to each other, but I'd like to be able to manage things in one place. Is it possible to do this in the latest version of ASP.NET dynamic data entities? If so, how painful is it? What I'm really looking for is a way to have routes for each database. So, for instance, I'd want /App1/Customers to go to the customers table in the app1 database and /app2/Locations to go to the locations table in the app2 database. Is there some way to rig something like this?
yes it is you just need to add multiple models David Ebbo has an article here Using Dynamic Data with multiple databases if you are using EF6 there will be changes to this method.
Related
I have a school management system built using Laravel and uses MySQL for database. In this system I want to be able to create a separate database for each school, how can I do that programmatically or via API
You are probably heading into an architecture called Multi-Tenant Architecture (MTA), and based on my experience, you can do that using one of these options:
External Library, I used Tenancy before for creating an MTA app, it is pretty awesome.
Manually, which has a lot of stuff to cover, but it is the easiest way to understand. For this option, basically you just add the foreign key to all of the object that you want to separate. For example, your database has schools and students tables, then schools is your tenant in MTA, which is the one that you want to make a different database, then students is the item that you want to keep separately in each of the database, then you need to add school_id to the students table.
Your wanted answer, which is mentioned here. I personally do not recommend this because this is just does not make sense that you called an Artisan command when your application is running programmatically.
If you have the time to research into MTA, go for the first option. If you have some time, second option is great, and if you don't have time at all, you can take the third option.
I know there are many questions like this and almost all answers are No. And the reason is a single microservice should be independent of another one. And if there is a change in a table, all microservices using that table need to be changed.
But my question is, if my database structure is fixed (hardly there will be any change in the table structure) will it be a good idea of creating multiple microservices pointing to same database.
Okay... here is my project.
We are going to a migrate struts 1.3/EJB 2.0 project to Angular/microservices. This project has 5 different modules and each module is a huge one. And this project is there in production since past 13 years. So there is very little chance of changing the table structures.
The reason I want to make different microservices is, since each modules are huge and complicated, and we still get requirements to add/change the business logics. So in that case, I can deploy only one microservice.
Any suggestions please.
I suggest creating a new service that access that database and all other services communicate with this service instead of directly to the database.
If you don't want to create a new service, at least access the DB using some database
abstraction layer.
For example, in SQL server use views and store procedures instead of directly access the tables.
I'm developing a multitenant application using Laravel. I've read different blogs, posts, sites for this and I decided to do it with a single database.
So, I know that I only need to filter every query with the tenant_id and that's it! But if I do it from every query, probably someday there'll be an error and I don't want to cause any information security issue for my tenants.
I read, probably, an old article for it, culttt.com/2014/03/31/multi-tenancy-laravel-4, and I found many concepts that I still don't understand because I'm new to Laravel.
Is this approach still the best for do it? Or has Laravel now its own solution to do it?
I like something similar to this: stackoverflow.com/questions/33219951/php-pdo-add-filter-to-all-queries but from Eloquent. How can I do this?
Thanks.
If I were you I would not go this way. I would create separate database for each client/each app - it's much safer solution and in addition in case you will need create Database backups or restore some client data it will be much simpler to do that than dealing with huge database when you have all your clients.
I've recently started to play around with ASP.net MVC3 and the Entity Framework. I followed tutorials (code, model and database first) and I liked alot of the automagical things happening.
BUT (always a but...), it seem to me that the whole "system" is very much constructed for someone hosting the whole thing by themselves with total control. I'm trying to understand how it can be useful to me in my hobby projects and self learning and so far I've failed.
What I'm getting at is this: I have a pretty regular web hotel, I own a couple of domains there. But I only have 1 MS SQL database. And it seems which every way I go with code, model or database first my sites/projects/tests fight eachother in that database - dropping eachothers tables.
On the web hotel I have to use a package from NuGet so that only tables are being created on model change - no database dropping allowed. But tables that not exist in one sites project are being dropped and conflicts arrise.
Am I missing something or did they really not construct the framework for people like me?
If I had a MS SQL database dedicated for each site I want to work on it would work of course but since that is an extra service it will get very expensive. And my projects are very tiny at this pont so having them share a database is no problem performance-wise.
Can anyone advice me, say what point I'm missing or point me in the right direction?
Thanks in advance!
It sounds like you're using the code-first variety of EF. Try the database-first variety and generate your model from the database, rather than vice versa.
We are designing our new product, which will include multi-tenancy. It will be written in ASP.NET and C#, and may be hosted on Windows Azure or some other Cloud hosting solution.
We’ve been looking at MVC and other technologies and, to be honest, we’re getting bogged down in various acronyms (MVC, EF, WCF etc. etc.).
A particular requirement of our application is causing a headache – the users will be able to add fields to the database, or even create a whole new module.
As a result, each tenant would have a database with a different structure to every other tenant using the system. We envisage that every tenant will have their own database, rather than sharing a database.
(Adding fields etc. to the system will be accomplished using a web interface).
All well and good, but the problem comes when creating a data model for MVC. Modifying a data model programmatically to add a field to a table seems to be impossible, according to this link:
Create EDM during runtime?
This is a major headache for us. Even if we don’t use MVC, I think we’d still want to create a data model (perhaps for used with LINQ to SQL).
We’re considering having a table with loads of fields in it, and instead of adding fields to the database we allocate an existing field in the table when the user wants to add a field to his form. Not sure I like that idea, though.
Of course, we don’t have to use MVC or Entity Framework, but it appears to me that these are the kind of technologies that Microsoft would steer us towards for future development.
Any thoughts? I’m assuming that we’re not the first people in the world to consider this idea of a user-customisable application.
I'd make sure that you have fully explored the option of creating 'Name-Value Pair' type tables as described here http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_nvp
before you start looking at a customizable schema. Also don't forget that you are going to have to grant much higher permissions to your sql accounts in order for them to create tables on the fly.
A customizable schema means that your sql accounts will also need much higher permissions. It wouldnt be advisable to assign these higher permissions to a tenants account, but to a separate provisioning account which can perform these tasks.
Also before investing effort into EF - try googling 'EF Vote of No Confidence'. It was raised (i believe) mainly in reaction to earlier versions but its definately worth reading up on. nHibernate is an alternative worth investigating.
Just off the top of my head it sounds like a bad idea to allow users to change the database schema. I think you are missing a layer of abstraction. In my mind, it would be more correct to use the database to hold data that describes the format of a customer's data. The actual data would then be saved in a text column as xml, including version information.
This solution may not fit your needs, but I don't know the details of your project. So just consider it my 5 cents.
Most modern SQL databases today supports the 'jsonb' type for key/value storage as a field. Other types (hstor for postgres) exists too. Forget about XML, that's yesterday and no application with respect for itself implements XML unless it is for importing/converting old data.