I am using MVC 3 and LLBLGen. I am confused about approach on populating ViewModels that have data coming from multiple tables. How would i display the Foreign Key names instead of just ID? I don't have any virtual keywords like entity framework. Should i just resort to using SQL Views and then populate viewmodels through them? Just to elaborate more, let's say i want to display more than 100 results at a time and each result has multiple associated foreign keys then how would i display their relevant names rather just IDs?
IMHO, your choices are:
Fields Mapped onto related fields. This has the advantage that you are still using normal Entities.
TypedLists. This is like views, but the building blocks are entity relations and entity fields.
Use TypedViews, that are actually DB Views.
Use your own types, like DTO's or JSON projections. After all you are doing a kind of mapping between your business facade objects and the objects you use to show in your UI.
Related
I'm starting to write a project and its my first time using ASP.NET MVC and Entity Framework (since now I've used PHP for around 5 years).
I got categories and posts, each category has to have its own unique filters that can be strings or Booleans (I'll get them via textboxes or checkboxes). I'm starting to get confused when designing the entities.
I'm using code-first approach but don't know how to set-up custom fields in Entity Framework. If I'd design that in PHP and pure SQL, I think that in order to keep it perform good, I'd create extra columns on the fly (e.g. "filter_1", "filter_2") and then create mapping table that contains the description of the field, the type, etc. and I didn't figure out if this kind of implementation is possible in EF.
I've thought about some options:
- I can create the filter using many-to-many relationships when creating a filters and filters-values tables and when creating a post add the filter values into that table. The main con about it is he performance - I'll most likely have 40k+ rows and more than 20 custom filters for sure... so searching and data fetching will be too slow...
- I thought about serializing the filtered values into some form of content, for example into bytes array and then only desterilize it - but the problem is that I won't be able to search within that...
- I can use the traditional ADO.NET way in order to create my initial idea (that I've described when talking about PHP - using the "filter_N" columns) but that'd create too much mess with EF...
There's any other way to achieve my goal (to create custom filters)? any way to create custom fields using EF?
Thanks for your help!
I don't know of a good way offhand to implement this in the Entity Framework. If you really wanted to use the Entity Framework I believe you could design your database tables in such a way that you wouldn't have to create the extra columns on the fly. You could have separate tables to hold the filters and relate them back to categories.
I am using Telerik open Access, I have three different data models like:
UserEntitiesModel->account_details
ProfileEntitiesModel->biographic_details
ContactsEntitiesModel->contact_groups
I have three different tables in different data models. I want to load the data from all the tables; I used joins and wrote the lambda expression, but it is throwing an exception
InvalidOperationException unhandled by user code
Can you tell me how to retrieve the the data from different tables in different data models?
You see, different models (rlinq) files generate different Context objects (the ones deriving from OpenAccessContext), they in turn have different internals used and are completely separate. This means you cannot combine them in a LINQ query.
LINQ queries are per-context and are (usually) executed on the sql server. OpenAccess cannot know how two models correlate and whether they are from the same database instance.
That being said, if the data models are just different parts of the same database (and use the same (or similar) connection string) you should be able to aggregate the models into a single context object. The context objects are initialized with a MetadataSource, and you can merge the models you have into a single one, using the AggregateMetadataSource. You will need to implement your own Context object, and it is more work, but it should work.
If you don't want to go into such trouble, you can always enumerate the results from your tables using .ToList() before using them in the LINQ query. This however means that you will be retrieving more data on the client that you wouldn't need otherwise.
I have a MySQL database and would like to have a similar structure in Core Data. I am very new with using Core Data with Xcode. I have a few fundamental questions if I am doing the right thing.
My Mysql DB looks similar to this:
table.caveconditions
visibilityID
percolationID
xxxx
table.visibility
visibilityID
visibilityValue
...and so on. I would then connect the tables using JOINS
Now, I have done the Core Data modeling like this but I am not quite sure if this is the right approach.
Would be great if someone of you could tell me if this is the right way to do it. In the end I would like to use JSON strings to dump the mysql table into core data.
Thanks a lot
Chris
I have created the new schema. Is this right?
It looks good except for all the "xxxID" attributes e.g. caveID. You also need to follow the naming conventions.
You have the same attribute names with (presumably) the same values in two or more entities. This is necessary in SQL for joins but in Core Data, this is handled by objects and relationships.
Each object in Core Data is automatically universally unique. This means when you create a relationship from one object to another, that relationship concrete identifies on specific unique object.
This means you only need an attribute like caveID in the actual entity that caveID designates which in this case is (presumably) the Caves entity. You don't need the attribute in the CavesConditions entity or any other entity that has a relationship to the "Caves" entity.
(If the xxxID were just artifacts of SQL, you don't actually need them at in Core Data unless some external database your app interacts with requires them.)
A good rule of thumb to use is that any particular value should show up on only one side of a relationship and, ideally, only once in the entire data model.
Naming conventions are a little different than SQL. A Core Data entity isn't a table. An entity is more akin to a class. Each entity is supposed to describe a single instance of a managed object. How many of those instances end up in the object graph is irrelevant. Therefore, entity names are singular.
In this case, Caves should be Cave, Countries should be Country and so on.
Relationships are named after the entity they target. It is not immediate obvious but each reciprocal relationship (the default) on the visual data model editor is actually two relationships because there is one relationship description for each side. Each side has the name of the entity targeted. By convention to-one relationships have a singular name and a to-many relationship has a plural name.
So:
Caves.relConditions<-->>CaveConditons.getCave
...would become
Cave.conditons<-->>CaveConditon.cave
The naming conventions are important because Objective-C uses conventions names to generate and search for accessor methods.
CoreData is NOT a database. Remodel your data as simply as you can and in a way that suits how it will be used in your application and do not think about joins or structure based optimization. You do not have control over the backing schema of a CoreData object model. This is the hardest concept you must get over when starting to use CoreData, but once you do, you will be better off.
I have three databases, x, y, z. Let's assume MS can speak to all of them via odbc or something else.
When I was in webforms I would create a tableadapter and conduct a query. I could do this for each connection I had, so I had three queries.
I would drop each connection and dataset on my page. Each control I used would call the appropriate dataset and populate it's gridview or whatever. All was well. I had three databases, three hits, all on the same page, for one integrated page for the customer.
How can I do this same thing in ASP.NET MVC? Please.
Thank you.
You get your data from your databases and return all the results in your ViewModel
the simplest way would be to get it all in your controller, assign it to your model the send it to your view
Using ASP.Net MVC entity framework, create entity classes for each of the 3 databases (Here it's assumed that you are querying entirely different tables from 3 different databases). What you get here are 3 entity classes, each having it's own properties that directly correspond to the table column names you are retrieving. Now, you don't need to worry about 3 databases. Entity framework abstracts it into a set of properties that map into different tables in x,y and z databases you are retrieving from.
I have a simple database with 2 main tables with a many to many relationship through a 3rd bridge/join table.
This 3rd table has an extra field besides the two keys required, so that Entity Framework transforms it into a full entity rather than a many to many relationship between the other 2 tables.
I cannot change this third table in the database itself. Is there a way to ignore the extra field so that EF can do what I want, or a way to manually transform the bridge table into a many to many relation?
Yes, update the store schema (SSDL) to remove the additional fields and regenerate the MSL/CSDL. The easiest way to do this is to create your mapping with a DB which doesn't have these fields. It will work fine against the "real" DB at runtime.