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?
Related
We have a DB2 database which is used by legacy applications that we are in the process of decommissioning and we have an Oracle database that we are developing new applications for. In order to maintain compatibility with legacy applications until they are completely decommissioned and keep data in sync, we are using Atomikos for two phase commits. This however is resulting in a lot of duplicated entities and repositories and thus technical debt, because the same entities and repositories cannot be used by the same entity managers so we have to duplicate them and put them under different packages for the entity scanning.
In most cases we want to read data from the legacy database and persist to both, but ideally this would be configurable.
Any help on this would be greatly appreciated.
As a webapp novice, I'm not sure if I need to define models.py.
I already have a working Postgres database on Heroku that I've linked up with Postico and pgAdmin. Using these GUIs, it seems I can get and post data, and make structure changes very simply.
Most tutorials seem to glaze over the details and reasoning for having a models.py. Thanks!
Web frameworks typically enforce or encourage a Model-View-Controller (MVC) patterns that structures code such that the database code is kept separate to the presentation layer.
Frameworks like django come with and are more integrated with ORM functionality which is used to implement an MVC framework. The ORM allows you to programatically interact with your database without having to write sql code. It can let you create a schema as well as interact with it by mapping programming classes to tables and objects to rows.
Flask can be distinguished from many other web frameworks, like django, in that it is considered a micro framework. It is light weight and can be extended by adding extensions. If you need the database integration then you can use it with an external ORM tool like sqlalchemy (and optionally flask-sqlalchemy extension). You can then define a sqlalchemy model, for instance, in a file called model.py or schema.py, or any other name you find appropriate.
If you only need to run one or two queries against an existing postgres database and feel you have no need for the use of an ORM, you can simply use flask with the postgres driver and write the sql yourself. It is not mandatory to have a model.
A model/ORM can be beneficial. For example if you want to recreate an integration/test instance of the database, you can instruct the ORM tool to create a new instance of the database on another host by deploying the model. A model also provides a programming abstraction to the database, which in theory should make your code more database independent (well in theory, its hard to achieve this as databases can have subtle differences), and should make your code less tied to a specific database solution. Also, it alleviates the need of writing a language within a language (sql text strings within python code).
I got an existing database with many tables which are accessed using stored procedures only (no O/RM). I'd like to create new tables in this database using Entity Framework and the Code First approach.
Do all the tables in my existing database need to be modelized in my Entity Framework classes? Will I be able to hand-code only the new classes I need in my DbContext? Other tables really need to stay untouched and away from O/RM for the moment.
Note: I'm going to be using the latest EF5.
As for now the Power Tools only allow you to reverse engineer all tables and views in the DB, which can be a problem if you have a big DB, with hundreds of objects, you do not want to reverse engineer.
However, I found an easy workaround for that:
Create a new technical user for the reverse engineering. To this user you only grant permission to the tables and views, that you want to be reverse engineered.
Have fun!
You are under no obligation to map any given table with EF. If you already have a database, you may want to consider reverse-engineering your database with the EF Power Tools available from Microsoft. I did this recently with a MySQL database that I had for testing purposes and it worked quite well!
If you are new to EF an advantage is that the PowerTools write a ton of code for you, which will help you get a grasp on the syntax of Code First. You will need to modify the output but it is a great start. I really believe that this approach will give you the least headache.
The EF PowerTools can be found here: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/
I currently have an n-tier application using entity framework 4.0 and we're looking at synching the contents of database between redundant servers. Does anyone have any experience on tips on how best to approach a solution?
From an architecture point of view, you need to consider if you want to do this at the application level or the database level.
At the application level you could write to both databases any time you made a change.
At the database level you could use the replication tools build into the database that you use.
You could also use a 3rd party tool. There is also a sync framework available from Microsoft.
In my organization, we are just beginning to use the Entity Framework for some applications. In the past, we have pushed developers to utilize stored procedures for all database access. In addition to helping with SQL injection, we tried to grant logins access to stored procedures only to keep security relatively tight.
Although inserting, updating, and deleting are easily done through stored procedures in the EF, it appears to be difficult to use stored procedures to query data with EF. However, using LINQ or Entity SQL and allowing EF to create the queries means giving a user read access to the entire database.
How have others handled this dilemma?
What kind of data protection are you trying to apply?
With EF, you can write a unit testable business logic layer that will handle many more authorisation scenarios than you can do at the database layer (although I can see how multiple layers of security makes you feel safer):
Querying AD (is this user the manager of that user?)
Calling web services
Checking other environmental contexts
If your circumstances mean you're not ready to think of the database as a store for data rather than a security & business logic layer, then maybe EF isn't right for your project.
P.S. EF will protect you from SQL injection.