I have a problem. I am creating a webAPI with ASP.NET MVC, I've got three different projects with three separate databases.
I have a method to do an Insert in one table. That table exists in three databases.
The client sends me the project in a String.
My question is:
1 - Should I divide the webAPI in three different URLS?
2- I don't want to create a switch or if-elseif in the controller this way:
switch (project) {
case project1:
objectdatabase1
case project2:
objectdatabase2
case project3
objectdatabase3
}
Because I think it breaks the OPEN CLOSED Solid principle.
3- Also I would like to inject de database object into de controller with Unity doing dependency injection.
Any ideas to do these in the best way possible?
Thank you!
Depending on what you are using to connect to those databases you might be able to just use named connectionStrings. Name them like the projects (whatever string the client sends) or have some convention (like param+"_connString").
Then have your DB access object open a connection using that particular connectionString and run whatever query you want.
Using specialized naming convention (like Project1_SomeKeyword_connectionString, Project2_SomeKeyword_connectionString etc.) just for this case will limit the potential security problems, in case someone would maliciously try and guess connectionString name that should not be used for that purpose (for your internal db or whatever).
If you are using plain SQL access object that will run whatever query you ask it to, it will be fine. If you are using some ORM that depends on a particular table-object mapping, you might need to create that ORM just for this purpose, if the rest of DB differs.
You were also mentioning that you might want to inject the database object. But wouldn't injection take place before the controller actions are being executed? That would mean that you must know which DB you are using beforehand, and you've said that the project name is provided during action call. You might need to inspect the request during injection and it makes it all kind of complicated.
How about create several EntityFramework models? So each model will connect to a different database.
Related
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 Jokenpo Game using React with Spring Rest, but I can´t have a database to store all the information needed(create and delete moves, create and delete players).
I don´t know the best practice of development, or if there is some design pattern on how to store that kind of information. I know there is the folder src/main/resources where maybe I can store a text file there and thought about on the startup of the api it loads that file with the begin of the game, maybe, and after changing it during the game.
Trying to be more clear: I just would like to know the simplest way of storing information without being a database inside of a Spring Rest application. I really appreciate any helps. Thanks.
Take a look at SQLite. It's a very light database library that you can include as a dependency of your Spring application, It doesn't require a separate database server to run, and the entire database is stored in a single file, that you can choose where to store in the connection string.
It offers the flexibility of a standard database, so you can use Spring Data / JPA to access the data. It has some limitations compared with robust databases like MySQL, specially related with concurrent writes that you should investigate and be aware of. Usually it works very well for small applications or embedded applications.
In Mvc3 it is necessary to use EDM or we can use normal process. if we go for normal process how can write the SqlCommand,SqlDataAdapter to conctact database. Is there any reference it is more use full.
No, it is not necessary to use EDM, you can use an database that you wish.
As per most websites, you can develop a standard Data Access Layer that encapsulates this code and call this from your MVC controllers, or from an additional Business Logic Layer.
The actual implementation of the Data Access Layer is not detailed here and you can find many examples of approaches for this by searching SO and the internet in general.
MVC is built on top of ASP.Net, so everything you used to use such as SqlCommand, SqlDataAdapter to connect to database can still be used.
Read this
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.
I have lots of databases to hit and put in one page. Most of the frameworks only allow me two native configure them for one database. They all assume the usage is for a new app and one database. I have lots of legacy databases.
Since I can only configure one database in frameworks I have seen ci, zend, others, it looks like my additional db connections have to take place in my controller.
What could I code on the back end to keep them out of the controller. I don't want to have to put in connection=myconn, etc. in each controller for each disparate database.
Also, are there any frameworks that allow for multiple databases in the ORM mapping?
I separate my controllers from my database with events. I fire some abstract "SaveWhateverComplicatedData" event from my controller, and a different class (who knows about all of my data storage specifics) listens for those events and interprets them. It's working quite well for me, and, though I only have one DB, I don't see any reason I couldn't have more.
This is a custom framework I've set up myself, but you could hook into another framework by wrapping these "data events" up in an interface that looks like a database. You could implement whatever interface your framework needs WITH the data events, and still have your listening multiple-database class doing the real work.