Working on my first Microsoft NoSQL application and I am struggling with architecture. The CosmosDB tutorials are understandably but frustratingly rather basic. The ToDo app tutorial here simply describes CRUD operations on a document of type Item - with very simple views and use of scaffolding.
My views are rather more complex and require additional information. I seem to have several options but I am unclear on the best approach. I could..
Make the JSON document fit my view. I am uneasy about this due to mixing of view and 'domain' data - but this is from my relational DB viewpoint. Also when I POST I will need to account for updating of duplicate view data within the same document.
Create a bunch of View Models and map these. This would be my normal apporach but this seems to add a signifcant overhead just to add a few extra fields to what is a JSON object. I have not looked at AutoMapper for .NET Core - perhaps this would be a more attractive option.
Use dynamics in some way. Microsoft has an example here.
Has anyone had a similar issue when moving to this new database - and could recommend an approach - and ideally point me to some online example/documentation?
Thanks!
Related
I'm currently using simple schema to manage my mongodb designs. I'm at a point where i have a number of collections and it can be a little difficult to visualize all of the collections while adding features to the app. Is there a graphical way to view the schema collections? Noob questions.
I'm not sure what you really want but if you're looking for a mongodb gui client then you can try MongoChef. But it's not interconnected to the simple schema package except if you're using collections2.
Hope this helps.
It is not possible to directly view the schemas of a collection until you have inserted a document.
I will advice seeding the collection with some sample data and then using meteortoys:allthings package to view the collections. (More info here)
I have ben following through a tutorial that shows how to get started creating a Web Forms Application in ASP.NET...and have got to the part where you create Data Classes. These assume you are starting from scratch and generating the database from code - however - I already have a database created and populated from elsewhere.
Entering line by line to create the Class for each table seems very laborious. (I'm using VB.Net and VS 2013 by the way)
Q1. Can anyone help by suggesting a more automated way of doing this? Surely there is a tool to grab the schema?
Q2. Although the tutorial mentions Entity Framework and Code Behind briefly - having done some reading and research - I am very confused by all of the different terms for data access. Am I using ADO.NET ?? Is the methodology called Code Behind as opposed to something else? Are there better ways to connect to a database and Read/Update/Delete records.
Q3. If I want to use a Data Grid to show the data do I use the generated classes to do this - or just 'bind' the grid directly to the database?
I have been a developer for 40 years but the newer .Net models are causing me some confusion so any advice gratefully received. (and any simple books or tutorials that can be suggested would be helpful).
Thanks
Q1: What you want is to generate "EF Designer from database" by using a Entity Data Model.
In your project add a new item and look under "Data".
What this technique does is auto generating entity classes from your predefined database.
Q2: I suggest you read Getting started with Entity Framework. "Database First" is just a description of how you want to use the Entity framework - by saying you already have a database structure.
Q3: In this case if you use Entity Framework and the "database first" mechanism to generate entities you can databind the gridview from the result of a entity LINQ query, please see this example: Tutorial: Databinding
I'm well aware of the standard SilverStripe Data Structure and table/field naming conventions. But how do you integrate SilverStripe with a pre-existing database? Is there any way to map existing tables/fields with a different naming convention to be useable by the SilverStripe ORM and DataObjects? Also, is it possible to use the ORM with two different databases?
In a recent project I had the same issue, and I solved creating views in the SS database over the CRM database, in order to present to SilverStripe the data in the way it likes. Obviously I also created DataObjects mapping the data, and so no dev/build is needed. It's not an easy way to do it, but if you're lucky and the second database logic is similar to SS logic it's a feasible task.
Now I have a CRM that write data into its database with its logic, and SS that reads it through views as if it were its own DataObject.
Good luck :)
I am afraid that, as far as I know, the answer to both questions is no.
I guess the best option would be to write an importer that connects to the old database, fetches the data, and then creates silverstripe objects for it.
If you have to run both systems at a time it will be come trick. The first thing I would consider here would probably be a rest api between the 2 systems, but not sure how well that would work out.
I just started working on an asp.net / C#.net application that is going to call a number of different procedures. The -only- thing these procedures do is create database table views, and the only thing I want to do is to store the information in variables. Then pick out which columns I want to convert to JSON, and then make a JSON string. I've actually written code for that in C#.net already, which is smaller, but since I switched to asp.net mvc I'm a little unsure if I should keep it or go with the whole Linq thing.
I checked out the Linq --> SQL drag & drop functionality, and that instantly created about 200 lines of code with set & get methods and everything.
So my question is, is it still worth using Linq even for just extracting data? Eventually this data will be fed to a javascript timeline, which is where I was told MVC would be highly useful with regards to Ajax functionality.
Since you are only using LINQ-to-SQL for data retrieval, I can't think of a single reason NOT to fully utilize it. I've been working on an MVC 1.0 project since last April. During that time, I've had to quickly become familiar with a number of technologies, LINQ-to-SQL being one of them. Get comfortable with it, and also look at the repository pattern...you will be very content and things will go relatively smoothly.
Now, when you get to INSERTs and UPDATEs, things are going to get a little more sticky. LINQ-to-SQL is still up to the job, but you'll need to understand how things work internally a little better. I highly recommend "Pro LINQ (Language Integrated Query) in C# 2008" by Joseph C. Rattz, Jr. The sections covering LINQ-to-SQL easily take up over a third of the book with detailed examples.
As far as the JSON objects go, LINQ-to-SQL's biggest contribution is that it allowed me not to have to worry about creating specialized views or stored procedures just to handle those one-off-types of data retrievals. My current project has a database of 65 tables...NO stored procedures. I can do filters, unions, multi-level joins...and it's all maintained in the application. Sweet...
Yes, it's totally worth it!
LINQ2SQL provides you a great subsurface to retrieve and save data to.
However, you'll need to implement your own Repository Pattern as you dig deeper into ASP.NET MVC.
And during the implementation of the Repository and the required (and even custom / webapp-state based) Queries, you'll be very glad to have all the power available at your fingertips that LINQ provides.
LINQ only adds to the available toolkit you can lean on when creating code. Even if you are using LINQ in a trivial way now, implement it, get familiar with it, and take advantage of the power it gives you both on this project and future projects.
Linq2Sql is quiet good for creating select queries. As it is appearing that you need to create JSON objects from database views it will be quiet useful
I'm creating a data model first using the LINQ-To-SQL graphical designer by using right-click->Add->Class. My idea is that I'll set up everything first using test repositories, design the entire website, then as a final step, create a database using the LINQ-To-SQL classes as a model for the database tables and relationships. My reasoning is that it's easy to edit the classes, but hard to modify DB tables (especially if there's already data in them), so by doing the database part last, it becomes much easier to design the structure.
My question is, is there an automatic way to link the two once I have the DB tables created? I know you can manually fill out the class properties for the LINQ-To-SQL entities but this is pretty cumbersome if you have a lot of tables to deal with. The other option is to delete your manually-created classes and drag the tables from the database into the designer to auto-generate the classes, but I'm not sure if this is the best way of doing it.
Linq to Sql is intended to be a relatively thin ORM layer over a database. While you can of course just add properties to a data context and use them as a sort of mock, you are correct, it isn't really easy to work with.
Instead of relying solely on Linq to Sql generated classes to give you freedom from the database implementation, you may want to look into the repository design pattern. It allows you to have a smooth separation between your database, domain model, and your middle tier; I have used it on two projects now, and have been able to (for the most part) build everything top-down, leaving the actual database for last. Below is a link to a good tutorial on the pattern (better than I could scribble down here).
https://web.archive.org/web/20110503184234/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx
Depending on your database permissions, you may call your datacontext's DeleteDatabase() and CreateDatabase() methods as a ungraceful way of resyncing your classes and tables. This is not much of an option when you have actual data in the database, but does work when you are in your development stages.
Take a look at my add-in (which you can download from http://www.huagati.com/dbmltools/ , free 45-day trial licenses are also available from the same site).
It can generate SQL-DDL diff scripts with the SQL-DDL statements for updating your database with only the portions that has changed in the L2S model (e.g. add missing columns, missing tables, missing FKs etc), instead of the L2S-out-of-the-box support for recreating the entire db from scratch.
It also supports syncing the other way; updating the model from the database.