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.
Related
I am developing an ASP.NET MVC4 web application. It uses the entity framework for data access. Many of the pages contain grids. These need to support paging, sorting, filtering and grouping. For performance the grid filtering, sorting, paging etc needs to occur on the database (i.e. the entity framework needs to generate a suitable SQL query). One complication is that the view model to represent the grid rows is built by combining the data from multiple business entities (tables). This could be simply getting the data from an entity a couple of levels down or by calculating it based on the values of related business entities. What approach is recommended to handle this scenario? Does anyone know of a good example on the web? Most have a simple mapping between the view model and business domain model.
Update 28/11 - To further clarify the initial display of the grid and paging works performs well. (See comment below) The problem is how do you handle sorting/ordering (and filtering) when the column that the user clicked on does not map directly to a column on the underlying business table. I am looking for a general solution to achieving this as the system will have approx 100 grids with a number of columns each and trying to handle this on a per column basis will not be maintainable.
If you want to be able to order a calculated field that isn't pre calculated in the database or do any Database Operation against it, then you are going to have to precalulate the value and store it in the database. I don't know anyway around that.
The only other solution is to move the paging and sorting etc to the web server, I am sure you don't really want to do that as you will have to calculate ALL the values to find what order they go in.
So if you want to achieve what you want - I think you will have to do the following, I would love to hear alternate solutions though:
Database Level Changes:
Add a Nullable Column for each calculated field you have in your View Model.
Write a SQL Script the calculates these values.
Set the column to Not Null if necessary
App Level Changes:
In your Add and Edit Pages you will have to calculate these values and Commit them with the rest of the data
You can now query against these at a Database level and use Queryable as you wanted.
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.
Say I have a client dataset CDSPerson that acts as a wrapper around a Persons database table. Say I have another table, PersonBenefits, that joins 1:1 back to the Persons table.
Say I wrap a Delphi class around CDSPerson, PersonClass, and another class around CDSPersonBenefits, PersonBenefitsClass, to read and write records. PersonBenefitsClass inherits from PersonClass so it can provide data from both tables. I'd like to be able to write data back to either table through PersonBenefitsClass.
Has anyone developed a clean way to handle the SQL query, provider flags and commit logic in the inherited class so that (a) fields stay aligned with the parent class and (b) both database tables can be updated?
Is there a reference for this that I can't find? Is this just a bad idea? I'm using Delphi 2007.
If you're going to develop a business-object-to-database mapping framework, (commonly known as ORM, Object-Relational Mapper,) you're going to need to put in a bit of architecture to make relationships like this work properly. Here's one way to do it:
PersonClass and BenefitsClass both inherit from BusinessObjectClass. BusinessObjectClass is a base class that contains the general logic to interact with the dataset. It has a list object of some sort that contains a list of relation objects.
Each relation object is a special object that contains either one or a list of BusinessObjectClass descendants, plus extra data describing the foreign-key relationship between the two tables. When BusinessObjectClass does its queries and its updates, it needs to iterate through all its relation objects and have them do their own queries and updates as appropriate.
In your composite object, (PersonWithBenefitsClass,) in the constructor, call inherited and then set up a relation object that describes the related BenefitsClass. Make sure that any inserts of new objects are done in the right order to preserve referential integrity.
That's the basic idea. (One basic idea. There are probably plenty of other ways to do it.) I'll leave the details of exactly how you implement it up to you.
I've read the manual and saw some tutorial, but still, I do not understand this point.
If I use Core Data in my app, lets say I have an object that one of its properties (column in DB) is a type field. In SQL i would do another table with types and do a many-to-one connection between them.
Now, In the tutorials they say that core data is not SQLite and i should regard it as a representation of an OOP objects.
So, should I do it the same why I would in SQL? types table and a field in the object table that is a foreign key for the types table or should I create a parent entity and inherit from it, creating a new entity (class) for each of the types I need?
SQL DB, as we all know, is a representation of a OOP schema, so I don't understand the benefit of doing it the hard way with inheritance. It is much nicer in my eyes to do it with a types entity, if possible...
Am i wrong about this?
Thank you,
Erez
In my opinion, these are the hard things. You'll always want to return to database designing. It can be better to use a separate 'table', but you can also use subclasses. Maybe you have an Item class, that can have different types. Then you can maybe create the subclasses CarItem, HouseItem... Each representing a certain type of the Item class.
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.