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.

How to design database subset classes with EF and ORM's

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.

fetching data from database ASP:NET MVC applications

Title is not the best but I will do my best to explain what I mean.
When you create ASP.NET MVC application and you need to fetch data about user profile (just an example) where do you place these files and how do you construct these queries (Lets assume that I'll use some kind of ORM like Linq 2 SQL and that I'll use ninject)
once again lets assume that will have interface which defines all details about user profile (name, surname, password...) now I wonder do you create methods for fetching data like (GetName, GetSurname...) and you define way you fetch data inside UserProfile class which inherits this interface we have defined or you define one method for getting all user account and then preform query inside controller.
If you have any useful links about designing(?) MVC application please post it

see my answer about how to properly layer an ASP.NET MVC application:
MVC3 and Entity Framework
such answer is in fact generic, subjective and does not apply only to web applications, same approach can be used for windows clients and other architectures.
There is nothing magic and actually this is subjective and also depends on experience, the general idea is to minimize or actually avoid dependencies between all layers above DAL and the ORM (if any) used to fetch/map data.

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