I need to query tables neither known or existing at compile time, publish the table via odata and then make it available to a silverlight client for CRUD.
Would be wonderful to use a PCO of type dynamic or ExpandoObject to acheive this but that doesn't seem to work (as suspected).
I'm wondering if there are Interfaces that would allow me to perform the type mapping and serializing at the row level so I would dynamically take the data row and round trip it's values on the server side. Perhaps an interface for the PCO to "help", or dynmically created property getter/setter. I'm also toying with dynamically creating the context class at run time but that's kind of ugly.
Then - on the client side, something to do the same thing with the odata feed, I have a solution here but it aint pretty enough to share with the world.
EF doesn't offer any "dynamic" approach as well as any simple way to let you create a new table and add it to mapping. Another question is how well can WCF Data Services work with changing data - I believe it is not supported as well.
If you want dynamically changed structure (added tables, columns etc.) use some metadata model instead of creating new table for each entity. Metadata model usually have something like table with common properties and related table with key value pair of attribute name and value. It can be futher extended to more complex scenarios but it is the only way how to achieve this. Instead of mapping in EF take your entity types as data.
Related
I'm creating a REST API which has a method to generate a price for an order. The parameters for the order are passed via GET request, and the logic for calculating a price based on those parameters is quite large and complex.
I'm wondering how I can move that logic out of the controller to keep the code DRY and tidy.
I feel like the best solution would be to have a Price model of some kind, which is a class not linked to a table but expects to be created with the required parameters, and can then perform various tasks and ultimately give a price based on the variables. I would also like to be able to perform validation upon creation of the model, so that it can check it has all the required parameters and that they are valid.
What is the best way to architect this?
How do I create an "imaginary" model which is not really a table or proper entity?
What is the best way to architect this?
By not using a table object because you don't want to interact with a table.
How do I create an "imaginary" model which is not really a table or proper entity?
Data processing belongs clearly into the model layer. Model is a whole layer and not just about databases. This is a common mistake. So simply create your own set of classes or single class in the src/Model/ or src/Model/Calculator/ folder like src/Model/Calculator.php and then simply use namespaces and autoloading for use it where ever you want to use that.
use App\Model\Calculator;
$calculator = new Calculator();
You can use that class in the beforeSave() of a table object for example if you want to store the price somewhere.
I recommend you to always think in terms of responsibility and concerns and how to separate them. The calculator should do it's calculations, nothing more, it doesn't need to know anything about a database connection or table to do it's job. Read about SoC.
Description of Goal
Trying to make a CMS (for internal use, but on many sites) with CakePHP.
I'd like to be able to have a generic Content model, then have many different user-generated content types.
This would be simple to do, but my single contents table would eventually become massive if every piece of content on the site was in it. I'd like to split it into tables to help query times/site speed...etc.
My thought (not sure if possible) would be to somehow tell CakePHP that if the type field of the Content is "article", that it should use the content_articles table...etc These tables would be generated afterSave (I suppose) when creating a new content_type.
Would be nice to give them options of which fields the specific content-type would use - even manage this by adding/removing fields...etc, then only generate those fields in the table, and somehow do validation on them based on the content_fields table data.
//my thoughts on tables:
content_types //id, name, description, use_table
content_fields //id, name, content_type_id, required, field_type, max_chars
content_articles //generated by code
content_people //generated by code
Questions:
Is it even possible? Are there better ways to go about this?
Perhapse use a key value table for content rather than a standard table? The utils plugin from CakeDC can do just that with a supported RDBMS.
Or, you could set this model to use a key value data source like MongoDB, which is a great use case for using NoSQL. I'd probably take that approach if you are talking about massive key value stores and a changing schema. There's a plugin for MongoDb on github.
I am working on an application which will require one or more additional fields to be added to a table in order to track user defined information. This additional info is only used for reporting purposes(Crystal Reports), and will have no effect on the behavior of the application. The data for this field is populated from an outside application.
What would be the best way to handle this additional information? Here are some options based off of other SO answers:
Entity-Attribute-Value (would this be overkill? Seems like there are many critics of EAV)
Add additional column to table (not sure how Entity Framework would like this)
Create a new Table for each UDF and use primary of parent table to link
If I understand the requirement correctly, you will need a datapoint to save information that would come from an external application and its structure is undefined at design time. if that is correct, then I would suggest using an xml datatype. by choosing this, you will not need to redesign your database in future when new key value pairs are inserted. Crystal reports should be easily able to include an xsl for this column.
Hope this help and good luck
I am putting together a WCF Data Service for PatientEntities using Entity Framework.
My solution needs to address these requirements:
Property DateOfBirth of entity Patient is stored in SQL Server as string. It would be ideal if the entity class did not also use the "string" type but rather a DateTime type. (I would expect this to be possible since we're abstracting away from the storage layer). Where could a conversion mechanism be put in place that would convert to and from DateTime/string so that the entity and SQL Server are in sync?. I cannot change the storage layer's structure, so I have to work around it.
WCF Data Services (Read-only, so no need for saving changes) need to be used since clients will be able to use LINQ expressions to consume the service. They can generate results based on any given query scenario they need and not be constrained by a single method such as GetPatient(int ID).
I've tried to use DTOs, but run into problem of mapping the ObjectContext to a DTO, I don't think that is theoretically possible...or too complicated if it is.
I've tried to use Self Tracking Entities but they require the metadata from the .edmx file if I'm correct, and this isn't allowing a different property data type.
I also want to add customizations to my Entity getter methods so that a property "MRN" of type "string" needs to have .Replace("MR~", string.Empty) performed before it is returned. I can add this to the getter methods but the problem with that is Entity Framework will overwrite that next time it refreshes the entity classes. Is there a permanent place I can put these?
Should I use POCO instead? How would that work with WCF Data Services? Where would the service grab the metadata?
This is definitely possible. What you need to use is QueryView which lets you control how a given column maps to a property on your entity. for instance here is something u could do on patients entity.
<EntitySetMapping Name="Patients">
<QueryView>
select value conceptualnamespace.Patient(p.PatientId,
cast(p.DateOfBirth as Edm.DateTime),
replace(p.Name,'MR~','')
from entitycontainer.Patients as p
</QueryView>
</EntitySetMapping>
i cover more on this concept in my book. the recipe is called.
15-2. Mapping an Entity to Customized Parts of One or More Tables
I work for a billing service that uses some complicated mainframe-based billing software for it's core services. We have all kinds of codes we set up that are used for tracking things: payment codes, provider codes, write-off codes, etc... Each type of code has a completely different set of data items that control what the code does and how it behaves.
I am tasked with building a new system for tracking changes made to these codes. We want to know who requested what code, who/when it was reviewed, approved, and implemented, and what the exact setup looked like for that code. The current process only tracks two of the different types of code. This project will add immediate support for a third, with the goal of also making it easy to add additional code types into the same process at a later date. My design conundrum is that each code type has a different set of data that needs to be configured with it, of varying complexity. So I have a few choices available:
I could give each code type it's own table(s) and build them independently. Considering we only have three codes I'm concerned about at the moment, this would be simplest. However, this concept has already failed or I wouldn't be building a new system in the first place. It's also weak in that the code involved in writing generic source code at the presentation level to display request data for any code type (even those not yet implemented) is not trivial.
Build a db schema capable of storing the data points associated with each code type: not only values, but what type they are and how they should be displayed (dropdown list from an enum of some kind). I have a decent db schema for this started, but it just feels wrong: overly complicated to query and maintain, and it ultimately requires a custom query to view full data in nice tabular for for each code type anyway.
Storing the data points for each code request as xml. This greatly simplifies the database design and will hopefully make it easier to build the interface: just set up a schema for each code type. Then have code that validates requests to their schema, transforms a schema into display widgets and maps an actual request item onto the display. What this item lacks is how to handle changes to the schema.
My questions are: how would you do it? Am I missing any big design options? Any other pros/cons to those choices?
My current inclination is to go with the xml option. Given the schema updates are expected but extremely infrequent (probably less than one per code type per 18 months), should I just build it to assume the schema never changes, but so that I can easily add support for a changing schema later? What would that look like in SQL Server 2000 (we're moving to SQL Server 2005, but that won't be ready until after this project is supposed to be completed)?
[Update]:
One reason I'm thinking xml is that some of the data will be complex: nested/conditional data, enumerated drop down lists, etc. But I really don't need to query any of it. So I was thinking it would be easier to define this data in xml schemas.
However, le dorfier's point about introducing a whole new technology hit very close to home. We currently use very little xml anywhere. That's slowly changing, but at the moment this would look a little out of place.
I'm also not entirely sure how to build an input form from a schema, and then merge a record that matches that schema into the form in an elegant way. It will be very common to only store a partially-completed record and so I don't want to build the form from the record itself. That's a topic for a different question, though.
Based on all the comments so far Xml is still the leading candidate. Separate tables may be as good or better, but I have the feeling that my manager would see that as not different or generic enough compared to what we're currently doing.
There is no simple, generic solution to a complex, meticulous problem. You can't have both simple storage and simple app logic at the same time. Either the database structure must be complex, or else your app must be complex as it interprets the data.
I outline five solution to this general problem in "product table, many kind of product, each product have many parameters."
For your situation, I would lean toward Concrete Table Inheritance or Serialized LOB (the XML solution).
The reason that XML might be a good solution is that:
You don't need to use SQL to pick out individual fields; you're always going to display the whole form.
Your XML can annotate fields for data type, user interface control, etc.
But of course you need to add code to parse and validate the XML. You should use an XML schema to help with this. In which case you're just replacing one technology for enforcing data organization (RDBMS) with another (XML schema).
You could also use an RDF solution instead of an RDBMS. In RDF, metadata is queriable and extensible, and you can model entities with "facts" about them. For example:
Payment code XYZ contains attribute TradeCredit (Net-30, Net-60, etc.)
Attribute TradeCredit is of type CalendarInterval
Type CalendarInterval is displayed as a drop-down
.. and so on
Re your comments: Yeah, I am wary of any solution that uses XML. To paraphrase Jamie Zawinski:
Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems.
Another solution would be to invent a little Domain-Specific Language to describe your forms. Use that to generate the user-interface. Then use the database only to store the values for form data instances.
Why do you say "this concept has already failed or I wouldn't be building a new system in the first place"? Is it because you suspect there must be a scheme for handling them in common?
Else I'd say to continue the existing philosophy, and establish additional tables. At least it would be sharing an existing pattern and maintaining some consistency in that respect.
Do a web search on "generalized specialized relational modeling". You'll find articles on how to set up tables that store the attributes of each kind of code, and the attributes common to all codes.
If you’re interested in object modeling, just search on “generalized specialized object modeling”.