We Keep Coding

C# Using multiple applications to connect a single database using Entity Framework

I am currently developing a Windows form application, that I plan to run on a cloud setup, the application will calculate new data, update within the database and act as sort of control panel for a live data feed RestFul API that I wish to create using ASP.NET MVC 5 Web API.
I am wondering is it viable to connect these 2 separate applications to a single database? It is unlikely that I'd have database entry clash issues as each application has a separate task of reading or writing data for certain tables.
If viable would that mean every-time i make table changes I'd have to update both Entity Framework database models? (Not a major chore).
Is there a better solution to this? Should I scrap the idea of running a Windows Form application to control certain elements of the backend of the public API?
What would be the future issues with designing something like this, if any?

So you have a bunch of options there, assuming you have a layered architecture:
Share your DB, DAL and also Business Layer
Extend your WEB API and utilize it in your WinForms
Reuse DAL only (not the best approach, as business systems are not only data, but also - behavior - which resides in Business Layer)
Share the DB only - this is the worst option, with numerous drawbacks
See options 1 and 2 on an image:

Create a Data access layer, as a seperate component.
like a DAL.dll
Each application has a Logic layer, where "whatever you do" is handled.
Each layer, now uses a sort of Interfacelayer, that will translate objects from either layer of your applications, to the objects of the DAL.
When you change the DB now - you merely have to update the interface layer.
(Of course if you are adding more features, you will have to update all layers, but that isn't really any different.
I suggest this appoach, as it will make your debugging task much easier. And the slight extra code overhead won't affect performance, unless you have a massive communication requirement.
If you want more specifics, I would need examples of a classes from either program, and your SQL table design.
But there is nothing wrong with your approach.

Share a database between an Azure Mobile Service project and an Asp.Net MVC project

I've two projects in the same solution, and I'm wondering what is the ideal way to share the database between AMS and the Asp.Net website. Also, as they both use Entity Framework of some sort, I found it tricky to keep the models synchronized between projects.
Idea 1: simply let them use the same connection string; but what if I used code-first migration in one project, and the other can't update because its migration history is behind?
Idea 2: doesn't let the Asp.Net website touch the database; let it communicate via HTTP requests to the AMS instead; but would that add additional network overhead for the communication?
Idea 3: create a separate project to contain all the entity framework classes and DbContext, and let both projects refer to it. But as the AMS project requires EntityData classes instead of POCO, it causes unimaginable trouble for me to reuse the model classes in other project. I just can't let the website start once I have all the mobile service nuget packages installed.
Any thoughts?

just a few thoughts on your question,
Idea 1: Will cause you trouble as you suggest when you preform EF migrations going forward. The models in each project may end up being different, EF won't like this. Best to stay away from this solution.
Idea 3: is what I tend to use in projects that aren't too heavy on usage and don't have a large codebase with infrequent updates. Create a single Data Layer project which contains all the EF context and migrations, then reference this data layer in multiple domain layers or front-end layers. This works pretty well and can keep things simple for you. Mobile Services exposes database entities via RESTful APIs so there shouldn't be too much trouble there. The Website should use DTOs and view models to move data around between layers. The only problem I have with this solution is when you update the EF models in one project, you will also have to update and publish the second project as EF models would have changed. To get around this I have automated the build and publish process, just to make the process a little easier to manage. Do consider the life of your solution, you may end up in a case where you're project data models diverge and you end up having two data models within one database. Splitting theses out later into two databases can be very painful when you have to bring the data with you.
Idea 2: In more complex cases, where I'm working on large project and continuously updating the code-base and the project is going to last into the foreseeable future, it's best to separate both services using an interface (which won't change too often) and remove the direct dependence on the shared database. You could as you suggest have the data stored in AMS and then just access it via REST requests from the website. Traffic can grow and may be a problem later depending on the demand of your site and mobile services which may slow down your response times to your website. Though initially, my concern would be in response time to your site from the many hops from the site to the mobile services interface to db then back again. Though you should be able to mitigate the effects with this with a cache for the read data, not the write data though.
What I would do in your situation, to make things easier on the deployment is to combine both the website and mobile services into one solution and host the combined website and API together say on an Azure Website alone, sharing the one data layer containing EF. Thus do not use Mobile Services if you do not have to, depending on requirements of course. ASP.NET can nicely support both under the one roof. This is a little outside of the scope of your question but something that might be useful to consider for your immediate problem.

What's the best way to reuse database access across multiple projects to ensure that when updated it does not break any projects?

I have probably written the same LINQ to SQL statement 4-5 times across multiple projects. I don't even want to have to paste it. We use DBML files combined with Repository classes. I would like to share the same Library across multiple projects, but I also want to easily update it and ensure it doesn't break any of the projects. What is a good way to do this? It is OK if I have to change my approach, I do not need to be married to LINQ to SQL and DBML.
We have both console apps and MVC web apps accessing the database with their own flavor of the DBML, and there have been times when a major DB update has broken them.
Also, since currently each project accesses the DB from itself, which is sometimes on another server, etc. Would it be possible to eliminate the DB layer from being within each project all together? It might help the problem above and be better for security and data integrity if I could manage all the database access through a centralized application that my other applications could use directly rather than calling the database directly.
Any ideas?

The way I handle this is using WCF Data Services. I have my data models and services in one project and host this on IIS. My other projects (whatever they may be) simply add a service reference to the URI and then access data it needs over the wire. My database stuff happens all on the service, my individual projects don't touch the database at all - they don't even know a database exists.
It's working out pretty well but there are a few "gotchas" with WCF. You can even create "WebGet" methods to expose commonly used methods via the service.
Let me know if you want to see some example code :-)

Dynamic N-Layer with ASP.NET

I'm trying to build a web application that let the administrator talk to the database through C# and add new tables and columns to fit his requirements (sort of a very simple database studio) but I'm not trying to just create some spaghetti application.
So I'm trying to figure out how to let those things dynamically (automatically) when he creates a table and use the table to build them :
1- The business objects or entities (the classes, it's objects and properties).
2- The Data access layer (some simple methods that connects to the database and add, update, delete retrieve items (objects)).
Is this possible ? any pointers on how to achieve it ?
EDIT
just opened your link!! .. it's talking about the data bound controls and stuff! .. my question is way more advanced than that!.
when you build an N-Layered application you start with the database schema and implementation and it's easy to do programtically then you start building the DAL classes which (add, edit, etc in other words the CRUD operations) in and form this database
what I want to do is to allow the web administrator to choose add the new table through my application and then -dynamically- the application would take the tables names and columns as parameters and create new classes and define within them the CRUD methods that will implement the SQL CRUD operations
then it would also create dynamically the classes and define within them the variables, properties and methods to call and use the DAL methods .. all this based on the table, column names
NOTE : All this happens on the run-time!

You might want to look into ASP.Net Dynamic Data. It's a RAD tool which very easily gives you CRUD functionality for your entities and more. Check it out.

Sometime back I had also asked similar question on SO. I got only one reply.
Today I was digging some information on MSDN and as I had guessed it, MS CRM entity model works based on metadata. So basically whatever a CRM developer is working against is just metadata, they are not real objects as such. Following is the MSDN link.
Extend MS CRM Metadata and here is the MS CRM 4.0 SDK.
I hope this should get you started.
Update: Recently hit upon Visual Studio LightSwitch. I think this is what we wanted to build. A UI which will pick up table information from DB and then create all CRUD screens. VS LightSwitch is in its Beta1 and has quite a lot of potential. Should be a nice starting point.

First, any man trying to create MS Access is doomed to recreate MS Access. Badly.
You are better off using ASP.NET Dynamic Data (as suggested) or ASP.NET MVC Scaffolding. But runtime-generated playforms that actually make decent applications are really pipe dreams. You will need developer time to do anything complex. Or well.

What you are asking is non-sense. Why? Because the idea behind BLL and n-tier is that you know your data model well, and can create a static class model to represent your data model.
If your data model is dynamic, and changing, then you cannot create a static BLL (which is what a BLL is). What you will have to do dynamically build your queries at run-time. This is not something that any of the traditional methods are designed to handle, so you must do everything yourself.
While it's possible to dynamically generate classes at run-time, this is probably not the approach you want to take, because even if you manage to make your BLL adapt to your dynamic database.. the code that calls the BLL will not know anything about it, thus it will never get called.
This is not a problem you will solve overnight, or by copying any existing solution. You will have to design it from scratch, using low level ADO calls rather than relying on ORM's or any automation.

What's the best way to set up data access for an ASP.NET MVC project?

I am starting a new ASP.NET MVC project to learn with, and am wondering what's the optimal way to set up the project(s) to connect to a SQL server for the data. For example lets pretend we have a Product table and a product object I want to use to populate data in my view.
I know somewhere in here I should have an interface that gets implemented, etc but I can't wrap my mind around it today :-(
EDIT: Right now (ie: the current, poorly coded version of this app) I am just using plain old SQL server(2000 even) using only stored procedures for data access, but I would not be adverse to adding in an extra layer of flexability for using linq to sql or something.
EDIT #2: One thing I wanted to add was this: I will be writing this against a V1 of the database, and I will need to be able to let our DBA re-work the database and give me a V2 later, so it would be nice to only really have to change a few small things that are not provided via the database now that will be later. Rather than having to re-write a whole new DAL.

It really depends on which data access technology you're using. If you're using Linq To Sql, you might want to abstract away the data access behind some sort of "repository" interface, such as an IProductRepository. The main appeal for this is that you can change out the specific data access implementation at any time (such as when writing unit tests).
I've tried to cover some of this here:

I would check out Rob Conery's videos on his creation of an MVC store front. The series can be found here: MVC Store Front Series
This series dives into all sorts of design related subjects as well as coding/testing practies to use with MVC and other projects.

In my site's solution, I have the MVC web application project and a "common" project that contains my POCOs (plain ol' C# objects), business managers and data access layers.
The DAL classes are tied to SQL Server (I didn't abstract them out) and return POCOs to the business managers that I call from my controllers in the MVC project.

I think that Billy McCafferty's S#arp Architecture is a quite nice example of using ASP.NET MVC with a data access layer (using NHibernate as default), dependency injection (Ninject atm, but there are plans to support the CommonServiceLocator) and test-driven development. The framework is still in development, but I consider it quite good and stable. As of the current release, there should be few breaking changes until there is a final release, so coding against it should be okay.

I have done a few MVC applications and I have found a structure that works very nicely for me. It is based upon Rob Conery's MVC Storefront Series that JPrescottSanders mentioned (although the link he posted is wrong).
So here goes - I usually try to restrict my controllers to only contain view logic. This includes retrieving data to pass on to the views and mapping from data passed back from the view to the domain model. The key is to try and keep business logic out of this layer.
To this end I usually end up with 3 layers in my application. The first is the presentation layer - the controllers. The second is the service layer - this layer is responsible for executing complex queries as well as things like validation. The third layer is the repository layer - this layer is responsible for all access to the database.
So in your products example, this would mean that you would have a ProductRepository with methods such as GetProducts() and SaveProduct(Product product). You would also have a ProductService (which depends on the ProductRepository) with methods such as GetProductsForUser(User user), GetProductsWithCategory(Category category) and SaveProduct(Product product). Things like validation would also happen here. Finally your controller would depend on your service layer for retrieving and storing products.
You can get away with skipping the service layer but you will usually find that your controllers get very fat and tend to do too much. I have tried this architecture quite a few times and it tends to work quite nicely, especially since it supports TDD and automated testing very well.

For our application I plan on using LINQ to Entities, but as it's new to me there is the possiblity that I will want to replace this in the future if it doesn't perform as I would like and use something else like LINQ to SQL or NHibernate, so I'll be abstracting the data access objects into an abstract factory so that the implementation is hidden from the applicaiton.
How you do it is up to you, as long as you choose a proven and well know design pattern for implementation I think your final product will be well supported and robust.

Use LINQ. Create a LINQ to SQL file and drag and drop all the tables and views you need. Then when you call your model all of your CRUD level stuff is created for you automagically.
LINQ is the best thing I have seen in a long long time. Here are some simple samples for grabbing data from Scott Gu's blog.
LINQ Tutorial

I just did my first MVC project and I used a Service-Repository design pattern. There is a good bit of information about it on the net right now. It made my transition from Linq->Sql to Entity Framework effortless. If you think you're going to be changing a lot put in the little extra effort to use Interfaces.
I recommend Entity Framework for your DAL/Repository.

Check out the Code Camp Server for a good reference application that does this very thing and as #haacked stated abstract that goo away to keep them separated.

i think you need a orm.
for example entity framework(code first)
you can create some class for model.
use these models for you logic and view,and mapping them to db(v1).
when dba give you new db(v2),only change the mapping config.(v1 and v2 are all rdb,sql server,mysql,oracel...),if db(v1) is a rdb and db(v2) is a nosql(mongo,redis,couchbase...),that's not work
may be need do some find and replace