I am working on an application where the ui may connect to multiple databases. Some of these databases have static schema. Others need to be queried based on schema provided by the admin (dynamically).
I want to be able to use the features of Entity Framework when working on the static databases and somehow use ADO.Net for the dynamic databases.
Also there is a possibility that a static db has 90% expected schema but few tables are generated dynamically. So I want Entity Framework to just work with the models I have defined. I dont want it to crib about the dynamic tables which got generated.
Is there a way ? Am I making sense ?
Try to refer this link and its too complex to map EF runtime so its better to go with ado on dynamic things and try to put static things in EF.
Related
I am switching over to Symfony for a project that I am working on but I need a little advice on how to structure the files when it comes to models and using doctrine.
I have a custom framework that I use, which in turns uses the MVC model. Pretty much all of my MYSQL database queries are stored in the models and I access them through the controller.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
I have also generated a number of Entities that correspond to my MYSQL database. My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
I'm a little unsure how to structure this.
Thanks
Pretty much all of my MYSQL database queries are stored in the models
That's bad, but I'll mention about it later.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
Queries should be done in either repositories or in some cases in services.
If your query returns entities, then it should be repository for sure.
My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
Entities should be plain PHP objects. They shouldn't depend on anything than other entities. Entities actually doesn't even know anything about database. It's pure object oriented business logic.
Again, all DB queries should be in repositories or services.
I would suggest to go through Symfony Book in first place, to get idea of how "the Symfony way" works.
Symfony is not MVC framework:
Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part [...] Symfony2 is an HTTP framework; it is a Request/Response framework.
And it is great. Symfony allows to make your model as you wish without any restrictions. The Doctrine (ORM and/or DBAL) is a separate set of libraries. You can use any other library, or build your own persistence layer abstraction, or work with native SQL through PDO/MySQLi/etc.
Service is just an object that registered in the container and have some dependencies. Services can doing anything. They can represent your model, but it is not a requirement.
Organizing Your Business Logic (The Symfony Best Practices)
Doctrine ORM Best Practices
I have the main website that uses a database to store and access user accounts. I'm using EF to manage the schema. I also defined site-specific POCOs and have migrated them to the database.
Now, what if I want a separate website, for example, a resource server (Web API) that would expose (with authorization) the same data set up on the main website?
Do I create the same POCOs and derived DbContext on the resource server again? That seems like duplicating work, though.
What if I wanted to create new POCOs on the resource server and reflect them onto that same database? Wouldn't that conflict with the current migration (which is saved on the database), then subsequently mess up the EF setup on the main website?
I've seen the suggestion of putting the POCOs and DbContexts in a library and have multiple projects reference that same library. This seems viable, however I'd have to hard-code the connection string, which seems dirty to me.
I'm starting to think that EF is probably not recommended for this kind of setup. It seems like a database-first approach plays better here - though I would have to manually reedit the data contexts (most likely, LINQ-SQL) for every database schema change.
Are there any lesser-known capabilities, facts, practices, etc., for/about EF that would help in this situation?
Generally, you can avoid duplication by having one API serving both sites and have resources version for each if needed. On the other hand, if you choose reuse and add approach, creating additional EF code-first entities should not interfere with other site data layer if modeled and mapped carefully. DbContext connection string does not have to be hard-coded.
I heard it is not a good idea to bring in the tables created by the aspnet_regsql.exe into your entity model. Can they just be removed from the model or is it a better idea to have it in a separate database?
The default is to create an "aspnetdb" database separate from your application database. You can name the database whatever you like, but having a separate Application Services database is the best practice. It isolates your user store and prevents any conflicts from occurring between it and any other database.
Furthermore, you want to use the classes included with the .Net Framework to interact with your Application Services database; it has its own data access layer separate from your EF classes. You don't want to use EF to work directly on the database, so it makes more sense to separate them.
The tables create with that tool are for the asp providers and used by them. If you use those tables in you model you run the risk of modifying data that the providers would not expect. If you remove them from your model you will remove this risk. You could potentially still modify the data via Execute() but personally I do not see a problem with them being in the same database.
I have read a bit about ADO.NET Entity Framework, but there is some things I am missing. Right now (not using EF, not sure what this technique is called, just ADO.NET?) we store all procedures in the database, that way if we have to change anything we have to just go into the db and change a query, pretty easy (other than the fact I have 100s of queries).
If I am correct with EF, I can query easier (no joins, shorter queries) but everything is saved in the Entity Data Model. So if I needed to change a query I would have to launch VS go in, find the location and change the query (which I guess would be linq-to-sql or Entity SQL to perform the query)
I just need some clarification about EF, and Entity SQL vs Linq-to-SQL.
Thank you!
When using EF you can use several types of data accessing:
Enity SQL - it is syntax similar to common SQL but queries are directly in code or entity model. If you want to change query you must rebuild and redeploy application.
Linq-to-entities - Linq queries on top of entity model. Again if you want to change query you must rebuild and redeploy application.
Executing stored procedures imported to model (also known as function import) - this is just sotred procedure exposed on your ObjectContext as .NET function. EF will handle parameters and result mapping.
Executing direct SQL by ExecuteStoreQuery or ExecuteStoreCommand (only EFv4). Here you can call any SQL including stored procedures.
So with EF you have both your current approach plus EF itself. Moreover calling native SQL through EF has some advantages like automatic mapping to prepared classes.
Anyway what you describe is quite uncommon situation. In many companies modifying something in DB requires same process as modifying application (or even more complicated) so you can't simply go and modify stored procedure in production.
How can we extend the Alfresco database? I need to add new tables to the existing database structure.
Does alfresco support this?
thanks in advance,
sri..
I think changing the alfresco db model is never a good solution. Some alfresco upgrades are made using Schema Upgrade Scripts, and that could get messy.
Have you tried to extend the alfresco content model?
Alfresco support some data types, allowing you to persist data. The Web Script framework allow you manipulate all your data inside your content model.
If your data is not suitable for a "content model", I think you should create a new database to hold your data.
Well, it is just a database. So you can create as many new tables as you want just like you would in any other database.
Obviously Alfresco won't use them because it doesn't know them, but you can query the tables as you like.
Advices from alfresco engineers are do not touch alfresco database. Please take a look at this page.
http://forums.alfresco.com/forum/general/non-technical-alfresco-discussion/where-alfreso-user-details-are-stored-i-alfresco
Changing alfresco database is not recommended.Content Model will be the good way.If such requirement is mandatory than,
You can use spring with hibernate for database connection.Properties which is required for connecting database are all ready declared inside alfresco-global.properties which is located inside "tomcat/shared/classes/".
For Spring bean injection you can declare beans inside any file which ends with "-context" which resides inside "tomcat/shared/classes/alfresco/extension" folder.
I will still recommend developer to use content model.
Depending on your use case, you may or may not need to play directly with the[/a] data base. I think your use case should fall in one of the following:
Use case 1:
You need to setup some metadata on folders and/or documents. You may have to nest multiple levels of nodes with different sets of custom metadata on each level.
You probably need to extend alfresco models in order to define custom document/folder models that best suits your business requirements. Please check jpotts' tutorial to learn how to do so.
Use case 2:
You need to define multiple lists with different sets of properties, those lists may or may not be linked to some content in your alfresco repo.
You probably need to learn more about alfresco sites' datalists, once you do so you may be interested in learning how to extend OOTB alfresco content model, jpotts' tutorial would be a good starting point, and then you should be checking this tutorial in order to learn how to manage datalists in stand alone aikau apps/share pages.
Use case 3:
You need to leverage a relational database in order to define and leverage you complex business logic that do not fall in any of the use cases defined above.
Are you sure you do not want to code a brand new app leveraging a technology that you are familiar with and have it communicate with alfresco using RESTfull api/cmis/.... ?
Are you sure alfresco is THE way to go ? If so, and you still want to have your custom complex business model in a bare relational database:
Please consider using a separate database instance / database for your custom extension, this way you would be sure any new patch/upgrade to alfresco that may change database structure won't affect your extension (or at least wont give you hard time upgrading it)
If you are really tied to only 1 database instance / 1 database schema, you will probably want to precede your table names with some prefix and hope none of alfresco future upgrades would have new tables with the same prefix. You probably also need to make sure to manage your database config wisely (connection pools ..) so neither your alfresco instance nor your custom extension have to starve. (make sure you close the connections you are opening)
Alfresco and Activiti come with a database. It is not good to access the database directly. Doing so can cause unexpected locking behavior or exhaust connection pools on the DB. This turns out into performance problems and other kinds of issues are possible too. In case you want to update Alfresco or Activiti you can do it through APIs. Easy to extend, easy to customize and hassle free integration capability are some of the reasons which has made http://loganwinson.doodlekit.com/blog/entry/4249216/top-things-to-know-about-alfresco-development>Alfresco web development popular among businesses.