We have a requirement where user can create a questionnaire and in questionnaire user can select any type it could be date,number,list or choice. To Store response of questionnaire in relation database we have everything as string, but that brings lot of typecasting problems when we report or fetch back from API or feed into reporting system.
I was thinking if we go NoSql route where it is schema less, we can create dynamic types and store in form of Json, so that when we retrieve types are maintained.
The question is what is the best way to define Objects in C# to read and insert into NoSql database or is there a better approach?
If you are planning to use the SQL API of CosmosDB then you have two options.
The Azure CosmosDB SDK for .NET has all the API logic you need in order to do all your CRUD operations in CosmosDB. It also supports mapping from the NoSQL document to your POCO objects.
Your other option is to use Cosmonaut. It is an ORM for CosmosDB that makes all of the above, really easy for you. It supports everything the .NET SDK supports plus some extra features regarding collection sharing and easy async operations that make integration with CosmosDB really simple.
Related
I want to create a platform that can read an XML or JSON configuration of entity names, their properties, and relationships and do basic CRUD operations on these entities as a starting point.
This means there will be no C# class definitions for these entities.
I would like to use a SQL Server database for this, however I believe it would be much easier to use something like a Graph or NoSql database since there is no predefined structure to create an ERD.
I would also like to use C#, Entity Framework, and JSON.NET to work with these dynamic entities and process business logic on them.
Another way of explaining it is the following:
Through a UI I would like someone to be able to do the following:
Create an Entity called Book.
A Book has the following properties: Title, Description, Author (one-to-one relationship w/ Author)
Create an Entity called Author.
An Author has the following properties: FirstName, LastName
What is a platform like this called and can someone lead me in the right direction?
What is a platform like this called and can someone lead me in the right direction?
Those applications are called Database Administration. Some examples are SQL Management Studio and PHPMyAdmin.
I want to create a platform that can read an XML or JSON configuration of entity names, their properties, and relationships and do basic CRUD operations on these entities as a starting point.
Why do you want to do it? We already have many application which has decades of developement efforts.
A quick search showed me a tutorial how to create one using ADO.NET. I haven't taken a closer look to it, but you can be sure, such an application is not as simple as following a tutorial.
I would also like to use C#, Entity Framework, and JSON.NET to work with these dynamic entities and process business logic on them.
Remember: Entity Framework is an ORM (Object-relational mapping tool). It's job is to high level map between your existing database and your application. You do not want to map your application code to a database, you want to administrate that database.
Therefore, EF is the wrong tool for the job. I think ADO.NET is the best you can do. You want to create a low level database application, so you need to use a low level tool.
That said, probably you want to just create some user defined content types? Then we are talking about a CMS. Probably you find some ideas in the Orchard Content Management System.
Is there a tool or framework to expose SQL Server tables and its data of as oData. Consider that tables are generated dynamically so using OR Mapper Entity Framework is not an option.
We need a mechanism to expose data as OData without generating C# classes.
There are a number of options here.
From a coding perspective, you can build something generic. .Net (C#) wraps OData support around the IQueryable interface and the [EnableQuery] attribute. The Pseudo code below demonstrates how you can do this generically with WebAPI2. A working demo can be stood up in minutes:
[EnableQuery(PageSize = 100)]
public IQueryable Get()
{
var data = (IQueryable)<get any data from the DB as IQueryable>;
return Okay(data, data.GetType());
}
Keep in mind that the filtering etc can end up being performed in memory, so trying to push as much of the filtering back to the database will give better performance. I have mainly used this with strongly typed objects and Entity Framework pushes all the filtering to the DB - very powerful and very quick. Keep in mind that OData is very flexible and you need to optimise your database indexes and queries for your common use cases.
From a Database perspective, if you are running in Azure, you have OData a few clicks away. See this article. Further Azure Table Storage's raw format is OData from the get go. Beware there may be limitations, for example, I think OData results from SQL Azure are paged to 50 rows to avoid denial of service type scenarios that thrash your database, especially for OData queries over non indexed data.
If your SQL is on premise, I don think there is anything out of the box, however there are a number of vendors that offer connectors. Here is an example from a quick Google. I have no affiliation with them.
I'm developing a .NET web service while trying to maintain a layered architecture that keeps my Models in one project and DB access (DAL) in a different one. The idea behind this is that if I have to change the DB technology, it's just a matter of creating a differnet DAL, while the rest of the application remains unchanged.
In the data-access layer that I'm developing, I am using Mongo DB C# Driver.
I've seen that:
Properties named "ID" will be mapped by the C# driver as the database's "_id" (Convention over configuration);
Int + Auto-increment in MongoDB is not a good idea;
Using Guid's as ID in MongoDB isn't a good idea either;
The recommended data type for the ID of documents stored in MongoDB is ObjectID. The C# driver provides a class to represent this;
However, if I use this data type (from MongoDB.Bson) in my Models, then they will become dependent on the MongoDB C# Driver and I don't want that: I want my models to be DB-independent; only my DALs can depend on whatever data access technologies I use.
So what data type should I use for my POCOs' IDs in order to have guarantee uniqueness in the DB? Would a string representation of a Guid be horrible in terms of performance?
Your feedback is welcome.
Good question.
From Experience, I can say that you're right: both GUIDs and auto-increment aren't the best idea (with GUID being a lot better than auto-increments), but not only for the reason mentioned in the SO question you linked to, but mostly because you need to be aware of the implications of monotonic vs. non-monotonic keys.
With the ObjectIds, I see three options:
Map between domain model and DAL. In the domain model, you could use the objectid's string representation. That's a bit annoying, but it forces you to separation of concerns.
Use your own data type and implement a type converter / mongodb serializer. I haven't tried that but I don't see why this wouldn't work.
Accept the MongoDB dependency. After all, if you really swap out your database, that will be a huge task. Different databases have very different characteristics and require very different data models. The whole "swap out the database" in a minute is bogus IMHO, it's never that easy and a database is a much leakier abstraction than anyone wants to admit. Trying to keep independent is a PITA. Anyway, doing a seek-and-destroy on the word ObjectId will be less than 1% of the other work.
I am building a web service that attaches to a database. I am planning to use EntityFramework ORM for my persistence layer. I have use a database first approach, designing my tables based on how I see the information mostly efficiently organized.
The ORM generates me some data entities in C#, but now I need to send a subset of that object data to my client via the webservice.
Example:
Say I have a User table with:
-Id
-Username
-Company
-Password
-Email
-AdminNotes
And say I want users to be able to request information on other users, but not all information. So in this scenario I would not want to share the Password, or the AdminNotes about the user. Should I create another Class to represent the UserProfile Summary and populate it manually from my ORM entity? Are there any special patterns I should use to populate these objects? Or can I create similar ORM objects that only represent subsets of the data?
Or should I be using various interfaces to represent my data types and simply serialize the interfaces?
I'm hosting my web service with ASP.NET MVC3 and am serializing everything with JSON. Will I experience complications trying to serialize these EF ORM objects into JSON?
Thanks!
So in this scenario I would not want to share the Password, or the
AdminNotes about the user. Should I create another Class to represent
the UserProfile Summary and populate it manually from my ORM entity?
Are there any special patterns I should use to populate these objects?
Or can I create similar ORM objects that only represent subsets of the
data?
Yes create ViewModels. You may also consider using Bounded Contexts.
The approach you choose would reflect YOUR preferred data access and layering technique you plan to use. Having Views ie special classes, used for Rest or Web Services and for MVC access is an often used pattern.
Or should I be using various interfaces to represent my data types and
simply serialize the interfaces?
Some people do serialize the Data Domain model. Others elect Not to.
Factors such as the use of Proxies influence such decisions.
I personally dont do that often.
I'm hosting my web service with ASP.NET MVC3 and am serializing
everything with JSON. Will I experience complications trying to
serialize these EF ORM objects into JSON?
Yes you can have headaches with serialization if EF proxies are used.
If you create special views over your domain and use one of the many mapping tools to populate the view or retrieve from the view, then you a less likely to have issues and UI and Service layer can be decoupled.
imagine you have service based directly on Domain class. What happens if the class is modified to reflect a DB change. ? Hard to shield that impact on consumers.
So yes i would suggest you do a ViewModel approach.
These sort of design / architecture question is one that start very long discussions.
Consider a bit of research to get comfortable with the topic.
I want to use SOA environment for my project. I have a several requirements:
1. Web site on Asp.Net MVC 4
2. CMS for the site - on Asp.Net MVC or Silverlight.
3. The mobile applications - iOS, Android, WP
4. Also, there are must be API for external services (pay terminal, web sites and other, mobile apps also can use this API)
Therefore, I want to use SOA. And I have one question.
The services coordinates the interaction between business objects and data access
objects by saving and retrieving business objects using DAOs (data access objects) to
and from the database. And, I must to convert entities to DTO and vice versa. I can use Autommaper for this, for example. But, I worry about performance.
For example, we have method in repository which return info about order. The Order have many FK to other tables. But, I need to only two tables. A generated sql contain many join for all references tables. Then we convert this order entity to DTO.
The question: how to or What I need to use for generating query that it will be lightweight and contains fields only needed for DTO? I must to use ExpressionTrees or something else, there are some examples or library?
Thanks and sorry for my English.
It looks like you need an ORM tool.
http://www.fluentnhibernate.org/ is good. If you want to stay with .NET you could use Entity Framework (but I'm not an expert in it).