I have a number of tables inside a database that I use for 4-5 different websites. These tables already exist and have plenty of data and views/stored procedures/functions etc. already completed.
I would like to provide an api to give access to each of these tables to whichever website I happen to be using so they're accessing the data in a consistent manner. I have Visual Studio 2015 and have been trying to create a Web Api using EntityFramework.
However, every tutorial I find for accessing databases insists on creating the database and tables within the code for the api, and utilizes just the tables with the various CRUD actions handled within.
As I have the tables built, I don't want to recreate them, and as I have some programming already in place using functions/stored procs, I don't really want to reinvent the wheel and recreate it all.
I did find this: http://www.c-sharpcorner.com/UploadFile/4b0136/working-with-stored-procedures-using-entity-framework-part/ for EF6 (though I believe I'm using EF7, but that seems to be importing each function in turn, which seems.. kludgy)
So my question is two-fold:
Is ASP.NET 5 web api the right tool for the job?
Can the ASP.NET 5 web api handle stored procedures easily?
At time of writing it's currently easier to build an API over an existing database using ASP.NET 4.6 and EF 6. This tutorial describes how you can go about building a model from an existing database:
http://www.asp.net/mvc/overview/getting-started/database-first-development/creating-the-web-application
Once you have a model and your classes in place, you can then follow any article on scaffolding Web API.
Related
the TYPO3 documentation here https://docs.typo3.org/typo3cms/ExtbaseFluidBook/6-Persistence/4-use-foreign-data-sources.html says, it is possible to use external data sources for extbase objects: "These foreign data sources could be tables from the same TYPO3 database or a web service."
The used data mapper allows at least to map objects to any table within the same MySQL database.
I am interested in this "or a web service" part. How to configure the data/property mapper to fetch and store an extbase model from an external web service (e.g. REST)?
Is it already possible with TYPO3 core? If not, does anyone know an extension which such capabillities?
You are looking at very old documentation there. Although this is still valid to learn Extbase concepts, I would not recommend the ExtbaseFluidBook for hardcore-details any more. I suppose the claim you quote reflects more of a wish or a slight possibility, not a reality. I am not aware of anybody having gone that route yet.
If I wanted to make an external source look "Extbasey", I would implement a repository and models but just use own logic to select and persist.
Side note: Typo3 v8 integrated doctrine, but only working with records, not objects (-dbal, not -orm): https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Database/Introduction/Index.html - this is used more and more in the core and in extensions. It might be feasible to include doctrine-orm and a doctrine-REST-backend like https://packagist.org/packages/circle/doctrine-rest-driver.
I followed very simple example from www.asp.net to create Web API project using Empty project template for Web API. This tutorial does not create database instead it just create model class and seed data inside api controller.
I successfully consumed API controller using angular service and able to show data on UI. Till here everything is fine.
However, moving one step further i would like create database but not sure about the steps.
I don't want to follow some other tutorial available on same site which does all of these things because i am not understand the overall concept even though i'll able to create database. Also, tutorial talks about using MVC approach which i dont want to use. I just looking for Web API, EF and Angular combination.
Can someone guide me for writing context class and overall database creation steps.?
We have a couple of large, mature apps installed in hundreds of medical clinics. These apps are built using Windows Forms and WPF and although we host the database for some of them, the majority of our clients have a local install of the database.
We are in the planning stages of rebuilding our application on the ASP.NET MVC platform using Entity Framework. We will also be re-architecting our database, but for reference, the current database has about 600 tables and 1900 stored procedures. Although we don't have an official DBA, we have enough DBA skills to build and maintain what we have, so we are capable of designing and building the data model ourselves. Also, we will continue to have both on-premise and hosted solutions.
Our struggle is with deciding how to use EF. We're all in agreement that we should use code-first, but some of us think we should build our classes, decorate them with attributes, and allow EF to generate the database for us. Others think we should design and build the database and then generate code-first POCOs.
Assuming we will have non-CRUD stored procs, triggers, views, stored procs, and user defined functions, is database generation a reasonable approach? Are there reasons why it might be the preferred approach? Any good reasons for avoiding it altogether?
I want to build a website that displays data from an external databases. The data must be displayed in the form of charts, because charts are more expressive. I've never developed any websites yet, can anyone give me some advice about existing web frameworks and what are the advantages and disadvantages of them?
Which framework should I choose? The data are stored in an SQL Server. Because new data report types might be required in the future, the framework must be easy to modify and expand.
This is purely subjective and there are many answers to this. With that said I'll tell you what I'd use:
You mentioned that your database is using SQL Server. I'll assume that you'll want to host your website on a windows server for sake of argument. Given that, I'd choose either ASP.NET or ASP.NET MVC given that they are natural picks for a windows server hosting websites on IIS. Then I'd find myself a nice jQuery charting plugin see this SO question.
I'm in the process of looking around at options for a back office tool. On the face of it the tool is simple CRUD so I was immediately attracted to Dynamic Data on top of Entity Framework (we're definitely a Microsoft shop!).
The problem is that future requirement is to support versioning. By this I mean :
User performs a series of updates to a series of entities
When they are happy they submit the changes
Changes persisted to the DB along with enough info to support a rollback
Elsewhere we've got handcrafted app that :
Includes a version id that is incremented as each new row inserted - i.e. we don't update we add a new row
A work item table ties together the changes using the version id along with the entity type (table)
So, the question is, how would I achieve a similar end result using entity framework and dynamic data?
If entity framework, etc isn't appropriate - what would you use (.Net)?
Thanks,
Alan
One solution would be to move the logic for the versioning to database triggers. This way you are able to use a standard Dynamic data on top of Entity Framework, and retrofit versioning by running a set of database scripts.
I would like to mention that in the new Dyanmic Data Preview 3 there is a new feature DomainService which supports Roles based security please see David Ebbo's Serssion from MIX09 here Microsoft ASP.NET 4.0 Data Access: Patterns for Success with Web Forms MIX09-T47F