I like to use the EntityFramework for persistence of the IndentityServer4 configuration data. But I was wondering why the same model Classes are duplicated in Model / Entities? Are both models always kept in sync? If I use the Entities, can I still include the Models project to use some convenient const and enum classes which are available in Models but not in Entities? Or is it better when using Entities to not include the Models library to prevent confusion.
Please advice.
The Models are duplicated in the IdentityServer4.EntityFramework library so that the models can be mapped to entities that make sense to Entity Framework (see the many lists of strings that need to be turned into entities so that they can be stored in separate tables). These entities are kept in sync by the IdentityServer team and the community.
There are mapper extensions for both types to convert them into one another: ToModel() and ToEntity().
Always use the Models unless you are communicating directly with the database.
Related
I'm planning to develop a web application in CakePHP that shows information in graphics and cards. I chose CakePHP because the information that we need to show is very structured, so the model approach makes easier to manage data; also I have some experience with MVC from ASP.NET and I like how simple is to use the routing.
So, my problem is that the multiple organizations that could use the app would have their own database with a different schema that the one we need. I can't just set their string connection in the app.php file because their database won't match my model.
And the organization datasource couldn't fit my model for a lot of reasons: the tables don't have the same name, the schema is different, the fields of my entity are in separated tables, maybe they have the info in different databases or also in different DBMS!
I want to know if there's a way to make an interface that achieves this
In such a way that cakephp Model/Entity can use data regardless of the source. Do you have any suggestions of how to do that? Does CakePHP have an option to make this possible? Should I use PHP with some kind of markup language like JSON or XML? Maybe MySQL has an utility to transform data from different sources into a view and I can make CakePHP use the view instead of the table?
In case you have an answer be as detailed as you can.
This other options are possible if it's impossible to make the interface:
- Usw another framework that can handle this easier and has the features I mentioned above.
- Make the organization change their database so it matches my model (I don't like this one, and probably they won't do it).
- Transfer the data in the application own database.
Additional information:
The data shown in graphics are from students in university. Any university has its own database with their own structure and applications using the db, that's why isn't that easy to change structure. I just want to make it as easy as possible to any school to configure their own db.
EDIT:
The version is CakePHP 3.2.
An important appointment is that it doesn't need all CRUD operations, only "reading". Hope that makes the solution easier.
I don't think your "question" can be answered properly, it doesn't contain enough information, not enough details. I guess there is something that will stay the same for all organizations but their data and business logic will be different. But I'll try it.
And the organization datasource couldn't fit my model for a lot of reasons: the tables don't have the same name, the schema is different, the fields of my entity are in separated tables, maybe they have the info in different databases or also in different DBMS!
Model is a whole layer, so if you have completely different table schemas your business logic, which is part of that layer, will be different as well. Simply changing the database connection alone won't help you then. The data needs to be shown in the views as well and the views must be different as well then.
So what you could try to do and what your 2nd image shows is, that you implement a layer that contains interfaces and base classes. Then create a Cake plugin for each of the organizations that uses these interfaces and base classes and write some code that will conditionally use the plugin depending on whatever criteria (guess domain or sub-domain) is checked. You will have to define the intermediate interfaces in a way that you can access any organization the same way on the API level.
And one technical thing: You can define the connection of a table object in the model layer. Any entity knows about it's origin but you should not implement business logic inside an entity nor change the connection through an entity.
EDIT: The version is CakePHP 3.2. An important appointment is that it doesn't need all CRUD operations, only "reading". Hope that makes the solution easier.
If that's true either use the CRUD plugin (yes, you can use only the R part of it) or write some code, like a class that describes the organization and will be used to create your table objects and views on the fly.
Overall it's a pretty interesting problem but IMHO to broad for a simple answer or solution that can be given here. I think this would require some discussion and analysis to find the best solution. If you're interested in consulting you can contact me, check my profile.
I found a way without coding any interface. In fact, it's using some features already included in the DBMS and CakePHP.
In the case that the schema doesn't fit the model, you can create views to match de table names and column names from the model. By definition, views work as a table so CakePHP searches for the same table name and columns and the DBMS makes the work.
I made a test with views in MySQL and it worked fine. You can also combine the data from different tables.
MySQL views
SQL Server views.
If the user uses another DBMS you just change the datasource in app.php, and make the views if it's necessary
If the data is distributed in different DBMS, CakePHP let's you set a datasource for each table, you just add it to app.php and call it in the table if it's required.
Finally, in case you just need the "reading" option, create a user with limited access to the views and only with SELECT privileges.
USING:
CakePHP 3.2
SQL SERVER 2016
MySQL5.7
Maybe this is a silly question, but I am new to large scale development in django. Basic django examples always show simple queries where you get a queryset and return the result set back to the template for use (e.g. a list of users). I was wondering is this really a best practice for a large site? Coming from the object oriented world, we have kept separate structures to loosely couple the database from business logic and views. One set of models would map directly to the tables in the database and use an ORM such as SqlAlchemy to automatically manage them but separate business models would be used to returned to the views for template usage based on business logic needs. They may have extra or fewer fields than the database table object depending on what information is needed for that template and come from a reusable code layer that contains the business logic. For example, sometimes you want to flatten a few columns from multiple database models in to one class that is easily consumable.
Also for situations such as transactions and connection handling, the reusable layer allows us to keep all knowledge of the database out of the views. The middle layer explicitly creates and uses a session to be used on different objects as needed and closes the session when done though I rarely see evidence of this done in django. While it is more development work, it tends to give better performance results. Is this separation of models and business logic all this considered overkill in the django world? Thanks.
From what you explain I get the sensation that you would like to build a middleware layer that caches queryset results in a reusable format.
Django takes the opposite approach: querysets are lazy. They do not touch the database until their result is needed in a view. When combining queries, it is only the combined query that hits the database.
Apart from that, caching and querysets gives good performance for most situations if you construct your models sensibly.
Not sure how to structure this. Model inheritance seems sensible, but it looks like Django will add a one-to-one link between the related models, which I don't need. Here's my situation: I have two models, for a Game and a Turn within a game. What I'd like to do is provide a "demo" version of these on my website for potential users to play around with. I want them to function just like the real models, but to populate different tables (eg say "demo_game" and "demo_turn") so I can clean them periodically and not "pollute" the real game/turn tables.
What's the best way to structure this? I could just copy the models to new versions, but would rather have a more elegant way to keep them in sync in case I modified one, but there is no need for any db relationship between a model and its demo version.
Create abstract base classes for each type, then derive concrete children.
Initially we wanted to clearly separate our database into logically separated entities. However we ran into several conflicts with our domain service classes.
Now it seems that the best approach for working with complex database models is to load all tables/stored procedures/views into one entity model and then separating the functionality through the domain service classes/repository classes.
Thoughts ?
What are your architecture approaches for laying out entities ?
Also are there any performance pros/cons of having everything in one model ?
Maybe separating model into several diagrams is a good idea?
The latest build of Entity Developer gives an opportunity to create independent diagrams containing different entities from the model.
In my database I have a User table with many related entities including Pets, Cars, Houses. More often than not my application will be working with just the User, however sometimes it will need to work with its related entities as well.
I'm planning to use Data Mappers (and Table Data Gateways) in Zend Framework. A few questions:
I think I'll have a BaseUser class, and an ExtendedUser class, with a Mapper for each. The ExtendedUser will inherit from the BaseUser, and the ExtendedUserMapper will inherit from the BaseUserMapper. Does this sound reasonable?
When my ExtendedUserMapper is working with related entities (such as a Pet, or a Car), it would call methods on a PetMapper, CarMapper, etc. Does this sound reasonable?
I am new to the Data Mapper pattern so am looking for a 'sanity check'.
Watch this presentation and you'll understand how to use services and data mappers.