Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I do have a database with multiple tables that represent different parts of the same DD object:
DD(ID*, name) (the name and ID of the DD)
DD_DATA(ID*, DD_ID(foreign_key), MONTH, YEAR, VALUE) (its annual data)
DD_MODEL(ID*, DD_ID(foreign_key), X_value, Y_value, Z_value) (its mathematical model, using a fk since it's a one-to-many relationship)
Since it's a huge application, I went to using ORMs, but I'm new at this. Currently I'm benchmarking and trying a lot of them, so I didn't settle yet with which one to use.
My question: Can (at least one) ORM be set to map these tables into a single object and translate the DD_DATA and DD_MODEL tables into some kind of arrays (or objects) inside one single DD class? Or do I have to do this by hand (I mean, creating a DD object and then extracting all its data by hand).
In Dapper, the mapping is done based on the results of whatever query you run. Your query can join many database tables - as long as the resulting column names match up to the object properties that you are mapping, you will be fine.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 months ago.
Improve this question
I have to store in database
[Column 1], [Column 2-start datetime]
Version1_1, 01-01-2011
Version1_2, 01-01-2011
Version1_3, 01-01-2011
…
I have a class with two fields: the version name and the datetime (+id).
The version name represents the first column. It can be an enum or a static class with constants.
Regarding almost any scenario I understand enums are better. But then, The DB will store integers in the first column instead of string values. Which gives me a feeling of uncertainty.
Are the enums still the best option in this scenario? I don't see disadvantages in lacking clean string values in [Column 1] in database.
If you store the values as integers in the database, you have several advantages:
Less storage space required
Easier querying without taking string comparisons into account
Better query performance because integer comparisons are much faster than string comparisons
A disadvantage on the database side is of course the reduced readability, but considering the advantages, I'd prefer integers in the database.
On the C# side, enums let you have the best of both worlds: integers inside and at the same time text identifiers when working with the values.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to programming an schedule in C# where I want to show all my tasks, for example:
01-20-2018 at 3pm meeting with boss. And have a question:
Should I create a table "task" where i save the date my id and boss id?
Would it overload the dB?
I need some tips, thank you!
How many interlocutors (bosses) will you have ? Certainly more than one.
I suggest you should have one table for each purpose :
A task_table for tasks with an ID_Task as primary key, Detail field, delay field, status field and son on.
A target_table for the targets which is/are involved in the task with an ID_target (primary key) with a name field, first name field, company field, observation field and whatever field you need.
And you link this two tables in an another one :
Rendezvous_table, with Id_rendezvous (primary key), datetimestamp field, Id_Task field, Id_target field and observation_field for observation on rendezvous.
This can be a good start. Beware the relations one to multiple, one to one, multiple to multiple. Multiple task for a same rendez-vous, only one interlocutor for one rendez-vous or multiple...
Hope it helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Let's suppose we have 2 tables:
Person
ID
Name
Nationality_ID (FK)
Nationality
ID
Name
With EF, in what contexts does it make sense and is correct to use each of the options below to add a nationality to a person? What is the different between them? What is the faster and the slower?
Option 1:
TheNationality.persons.Add(ThePerson);
Option 2:
ThePerson.nationality_id = TheNationality.id;
Option 3:
ThePerson.nationality = TheNationality;
If Person is the root of your aggregate and the focus of your application, most likely option 2 and option 3 make sense. Of those, option 3 is the more useful if you need to do additional domain logic based upon information in your nationality. Option 1 makes sense if the focus of your application is about nationality.
None of these methods is mutually exclusive. If you query and manipulate the objects from both perspectives, you can use options 1/3 or 1/2.
The resulting insert/update would be the same in all cases. Unless it is necessary to get TheNationality entity for some other reason, you could skip the read to obtain that and just assign the ID if you have it:
ThePerson.nationality_id = someNationalityIDVariable;
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
Working on a legacy application where Data Access repository always returns a data set. Changing to any ORM frameworks is not an option for me at this point, looking for best options to map result set to a CLR type
I know of 2 easy ways to do this.
1 - Use Dapper.NET
const string query = "SELECT * FROM Users";
return connection.Query<User>(query);
With Dapper you don't even have to worry about getting the DataTable, just query the SqlConnection and get your type back.
2 - Use Automapper:
List<User> users = AutoMapper.Mapper.DynamicMap<IDataReader, List<User>>(
sourceDataTable.CreateDataReader());
Automapper can map your DataTable to your type.
Both methods require your class to have property names that match the column names in your source data.
I think they are both available as NuGet packages
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is there any preference on either appending DTO or Entity to a class name?
Is there any standard around this?
1 Class is used by ORM (EntityFramework) and the other class is used for serialization.
The reason for this is so that there is no duplication of all fields as the EntityFramework is a wrapper around the DTO class(most but not all properties).
The DTO class is in a shared library, and decoupled from EF.
E.g. Which of these is the most common/standard approach?
// 1.
MyNamespace.Entities.MyClass
MyNamespace.Models .MyClassDto
// 2.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClass
// 3.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClassDto
In my personal experience your third example is the only implementation I have worked with and it is the one I would argue for because the intent of the object you are working with will always be clear whereas with the other two it only becomes clear when looking at both objects together.
That being said as long as your team comes to an agreement on which to use any would work.
In my opinion, you typically don't want to put implementation details into class names for similar reasons to why you don't want to use Hungarian Notation.
If there's a bit of code that needs to work with both types and differentiate between them, another option is including aliased using statements like this:
using entities = MyNamespace.Entities;
using dto = MyNamespace.Models;
//in code
var myClassEntity = new entities.MyClass();
var myClassDto = new dto.MyClass();
//work with both
My assumption is that the code that needs to work with both types is limited to an isolated library, and that client code typically works with one, not both types.