There seems to be a separate DbContext in the Host project as well as a DbContext in the EntityFrameworkCore project in abp.io project templates (at the time of writing). I was wondering what the intended purpose is for these DbContexts? If I want to create a monolithic application with a single database, which DbContext should I use?
Related
I like the idea that third part apps run at *.github.io *.shopify.com *.volusion.com works, people make own pages (modify/use template), and host inside.
I'm interested in architecture, how all of this happen?
Do they save files in disk, or write inside database
How easily manage dynamic subdomains?
What happens behind the scene?
What language they use?
This is called multitenancy. It can be achieved in a number of ways with on many different server platforms. There are a number of pieces, for example:
URL rewriting rules handled at the load balancer or web server level to let *.site.com act as site.com/users, or something to that effect depending on your platform architecture
A database of tenants (users) and their associated account names or subdomains
Routing or resolution code that conditionally switches the database connection (or tables, or security modifiers, etc.) per request based on the calling tenant
Ultimately, a tenant is just a row in a database table somewhere, and the application is written in a generic way so that each tenant uses the same "base" code. How that works and how it is implemented can vary greatly between applications.
Update: Per your comment, here are some resources specifically dealing with tenancy in ASP.NET:
Simple Multitenancy With ASP.NET MVC 4
Developing Multi-tenant Applications for the Cloud, 3rd Edition (free Microsoft ebook)
ASP.NET MVC 5, Entity Framework, Ninject and Multi Tenancy Setup
Multi-tenancy in ASP.NET MVC
I am working on an enterprise level project. DB is in MySQL and project uses Maven, Hibernate and Spring MVC. I've gotten through defining the data models now I need to start implementation.
My question is, is it better to create the service and implementation layers in separate projects or should they be in the same project as the data model layer? What are the pros and cons and how should I go about it please?
If it is just a web app and you won't share any code with other applications, then just put entities in one package, controllers in another package and so on. No need to create multiple projects. If your application is going really big or you have to share code with other projects, then you can think of separating.
I am doing a project in which it has been imposed that I must use Netbeans 6.9.1 and Rails 2.3.8. The operating system must be Windows and we are not allowed to use the command line. We are required to use a MySQL Database (already created and fully functional) and we must import the tables from the database into models, view, and controllers in the Rails project. I don't know how we're supposed to do this because the way Rails works implies that you use the application to make the database, but we have to use the database to make the application.
I've put several dozen of hours into looking this up but I've come up empty handed because every tutorial I found for Rails either uses the command line, or uses scaffolding to create tables to put in the database instead of vice versa.
The question is, how can I generate models, views, controllers, etc. from existing database tables using only the tools in Netbeans? I'm new to both Rails and Ruby so coding them all manually would be extremely difficult because all the routes go funny. If anyone has a solution it would be most appreciated.
Note: This is not about the difference between Database first, Model first, and Code first.
Microsoft has a number of tools to simplify using DbContext. Unfortunately, there seems to be almost no description and also no documentation on what they are, much less what they do.
What is the difference between:
Entity Framework Power Tools CTP1
ADO.NET C# DbContext Generator
ADO.NET C# POCO Entity Generator
I don't usually answer my own questions, but here is what I figured out:
The difference between the ADO.NET C# DbContext Generator and the ADO.NET C# POCO Entity Generator is that the former creates a context based on the DbContext and the latter creates them based on the ObjectContext.
Basically, these are used in the Model First and Database First approaches. The difference between Model First and Database First is that in Database First, you define your data model in the database, then reverse engineer the model (ie. create an .edmx file) from the database. While with Model First, you create your model in the designer (again, the .edmx file) or by hand, then generate the database from that model.
In both cases, you then generate POCO classes and either a DbContext or ObjectContext from the .edmx file.
The Entity Framework Power Tools CTP1 reverse engineers a Code First model from the database, including POCO class, the DbContext (don't think it offers ObjectContext generation) and the mappings (via the OnModelCreating method).
So what this boils down to is that in Database First and Model First, the "model" is defined by the xml .edmx file (or in some cases, several files). While in Code First, the model is defined using fluent code mappings in OnModelCreating.
When using the Power Tools to reverse engineer the database, it doesn't create an .edmx file, instead creating the mappings in code. Thus, skipping the xml middle man.
ADO.NET C# POCO Entity Generator exists for a long time and is part of the Mode First approach. Read about it here.
The differences between ADO.NET C# POCO Entity Generator and ADO.NET C# DbContext Generator are discussed here: ADO.NET DbContext Generator vs. ADO.NET Poco Entity Generator (ObjectContext).
Entity Framework Power Tools CTP1 is a drop of useful tooling for the project's context menu.
We’ll be releasing shortly a companion Rails application to our existing Rails app. We will be running the companion app alongside our existing app on the same servers.
My question concerns the databases. My hosting provider generally would configure a 2nd distinct database for the new application - secondappname_production. However, there are a series of shared tables between the applications. These shared tables are also maintained by a series of cron jobs. I would love to avoid duplicating these tables (and thus the cron jobs) if at all possible.
Is there a way that I can put these shared tables in perhaps a shared database that both Rails apps can leverage? Any suggestions as to how to configure that or documentation pointers?
Thanks so much!
EDIT: To clarify why I don't want to run both apps out of the same DB: Both apps have models of the same name (yet different attributes of the models, etc.), so I would prefer to not run both out of the same DB....
You can have some models in one database (the ones that you want to share), and others in the new app's own database (so they don't collide with the existing app).
To specify a different database for a particular model, try something like this:
class SharedModelBase < ActiveRecord::Base
self.abstract_class = true
establish_connection(ActiveRecord::Base.configurations["shared_db_connection_#{RAILS_ENV}"])
end
Now, use this as a base class for your shared models, and you should be good to go.
Part of your question is best practices, so a couple of other options.
One option is to not even try to access to the db directly, but instead build an integration between the apps using ActiveResource. Have the original app provide a RESTful interface to these tables, and consume it in the new app, and don't share the db at all. I like this option, but may not be clever for your situation.
Another option is to refactor these shared tables into their own database, and have both the rails apps access that db. You could even end up writing services (e.g. restful interface) to this shared data to be used by both apps, and then you are nicely decoupled.
Consider the complexities of when this shared db structure changes. If you are sharing the tables directly, both rails apps could have to be changed simultaneously to accommodate the change - you have linked your release schedule now, these apps are now coupled. If you wrap the access to the db in services, this can provide abstraction as you can serve both the old structure and new structure simultaneously by deploying the new updated service at the same time as the old service interface. It all depends on your app if such complexity is worth it.
I think what you want is share model,not only database table,in rails table is model based.
create main rails app -->rake g model User name:string->rake db:migrate
create shared rails app
-->rake sync:copy
-->(DO NOT generate same model in shared app, also do not db:migrate)
-->config/generater shared
controller and router.rb file(dependend your requirement)
sync.rake(appshared/lib/tasks/)
namespace :sync do
desc 'Copy common models and tests from Master'
task :copy do
source_path = '/Users/ok/github/appDataTester/appmain'
dest_path = '/Users/ok/github/appDataTester/appshared'
# Copy all models & tests
%x{cp #{source_path}/app/models/*.rb #{dest_path}/app/models/}
%x{cp #{source_path}/test/models/*_test.rb #{dest_path}/test/models/}
# Fixtures
%x{cp #{source_path}/test/fixtures/*.yml #{dest_path}/test/fixtures/}
# Database YML
%x{cp #{source_path}/config/database.yml #{dest_path}/config/database.yml}
end
end