We Keep Coding

What to use with a half-designed database? Model-First or Database-First?

Let's say you have a database that is currently in use. It has one table that contains some information about Customers.
And let's say that you want to create an application around it. You need to use the Customers table in your program, but you also need to add some new tables, possibly connected to the Customers. For example, you need to add an Orders table that has some association to the Customers table.
I have started to learn Entity Framework. I have learned a bit about "Database-First" and "Model-First" data models. But the situation is, what I want to do doesn't fit into any of these categories. I neither have a completely empty database, nor a finished database schema that can directly be used in the program.
What should I do? If I go with "Model-First" and design my entities using the Visual Studio Designer, can I just use it to create the relevant part of the database schema?

Go with Data-first, THEN go with Model-first. You don't have to pick... use the data-first wizard to generate EF for your existing table, then use the designers to create additional objects, then sync that back to your database. The concepts of model-first and data-first only applies to the initial creating of your EF stuff - anything you do after that can by synced in either direction.
This shows how to put database changes back into your model after it's created - you can do the other way too, but I can't find that article - all the new videos and crap are hard to navigate - you may be able to find it.
http://msdn.microsoft.com/en-us/data/jj206878
After all, the framework wouldn't be very useful if it locked you into never being able to update anything. Right?

The more development into your project, the more Database-First it'll become, so I suggest you to go with Database-First right now and then extent your EF entities and then implement/fake/mock the missing pieces
If you haven't read about TDD, it's time to do so now. It'll save a ton of time down the road especially when working with an ever changing data model.

MVC Model - one or more dbcontext in aplication (EF)

I am building MVC 4 application for some kind of web store. This is first time for me to do anything with ASP.NET so I spent some time reading about whole idea of mvc pattern, and how it is implemented in latest version.
I understood that I need to write Model for data, and I decided to do Code-first approach.
Also I like to different classes move in different files. And also different parts in different classes.
Now I not sure how should I organize model classes. When I make project with "Internet Application" template, I already get AccountModel with user information. It does not sound right for me that I should put information about products in that model. But if I make separate model I will need some kind of connection between this 2 models and I not sure how to make it.
Or should I put whole db in one model?

I would recommend putting everything into one Model, if it's possible.
Here's a couple of examples, from the code-behind point-of-view and databases:
I used a single Model, when I've had to access/manipulate data from a single database.
I used multiple Models, when I've had to access/manipulate data from multiple databases.
Most of the time I've only created a single data context, since multiple ones weren't logical. Why have multiple data contexts, if you only have a single database?
To answer your question: I'm not sure how complex this "web store" will be, but I'd advise to create a single Model. You can always move things around later, if necessary.

Data Access Framework that addresses my needs

I'm having trouble choosing an appropriate data access framework, partly because I'm very picky with my preferences and mostly because I don't have much experience with most of them :-)
I need a framework that will allow me to easily map between the DB tables (SQL Server) and my entities, and that will handle the CRUD operations for me (for the most part).
I want my entities to reside in a separate assembly from my DAL.
I prefer using attributes for the mappings over external file like XML.
It doesn't have to be an ORM, and I want to code my entities myself.
I don't mind writing stored procedures.
The project's database won't be very big. Less than 50 tables.
I'd like some of my entities to correspond to an inner join of two tables - one for static data entered manually during development and the other with data filled during runtime - without using two entities that reference one another (the result of this join will be a single entity).
Entity Framework sounded perfect until I realized it doesn't support Enums (yet - and I can't wait for EF 5.0).
I want these entities to include Enums, and plan on using lookup tables for the enums + code generation for the enum to keep it synchronized with the database.
Linq-to-SQL seems like a good candidate, but I don't know if it copes well with my previous demands.
Using Enterprise Library 5.0 DAAB with it's RowMapper, and extending it's abilities to perform updates and inserts is also an option (but will require more coding on my part).
I plan on implementing the Repository Pattern.
How about NHibernate? Would it do? No experience there either.
I would be happy to hear all suggestions.. the more the merrier! Thanks in advance!

I think nHibernate is the way to go, although some of its main strengths (ORM, stored procedure generation, etc) are things you listed as non-requirements. Anyway, nHibernate will do everything you want it to do. Technically it does use xml mappings, but these can easily be auto-generated using fluent attribute mapping. I like this, as it IS done for you, but you get the customization too just in case you need it. Good luck!

Multiple/Single *.edmx files per database

I have a project that interacts with a database through ADO.net Data Services. The database is large (almost 150 tables with dependencies). The project started a few years ago and there were DataSets used then; now we're moving towards entity model relationships. The model is growing since we are adding more tables we need to work with. Is this a right way to manage all that?. Meaning should I have a SINGLE database model file to have single data context?
What are drawbacks and how do you use the entity framework with large databases (or should it not be used with large ones?
The disadvantages I see are:
Visual Studio 2010 starts to freeze
when opening that large XML in the designer (maybe this is NOT a problem, because even with many tables it doesn't freeze for long time).
It becomes hard to find references in
the model (though F4 + properties window's combobox of object names almost
removes this search related problem).
PS, strange that no one answers. The question seems important and in simple words I'll just rephrase it: Which is better, one model of whole a whole, large database or several models of that database?

I suspect you aren't getting many answers because it's not a big problem. Even in both your disadvantages you say they're not really problems. Certainly EDM is fine working with big databases. I'd argue the larger the database the more the need for an ORM solution.
However you can have one model split over multiple files if that would help you keep things organised - i.e. multiple .edmx files can constitute a single data context.
Alternatively if you can logically split the model into isolated parts that can interact via interfaces rather then needing to directly join entities in the data context that is good for both managing the entity data model, and also just for basic separation of concerns.

Linq-to-SQL: how many datacontexts?

I have a SQL Server 2008 database with > 300 tables. The application I have to design is an Windows Forms app, .NET 3.5, C#.
Which is the best way to work with Linq-to-SQL ?
I intend to make a datacontext for each business entity.
Is there any problem ?
I need to know if this way of working with Linq-to-SQL has any disadvantage or can create performance issues ?
Thanks.

You should typically have 1 single DBML file (=data context) per database. You should certainly not create a DataContext per business entity, because doing this would make you lose most of the useful capabilities of LINQ to SQL, like memory transactions (unit of work), lazy loading, and doing LINQ queries over multiple entities.
You have a pretty big model (+300 tables) which means a lot of entities. A lot of entities is not a big problem, except for the LINQ to SQL designer. Using the designer with such big models can be pretty annoying. This can be a reason to split a domain in multiple sub domains (with each a DBML file), but certainly not one per entity. However, keep in mind that you loose the L2S capabilities at the boundaries of the domains.
In the past I advised a team, who had split up their +150 entities domain in 5 DBML files, to merge them back together to a single DBML. The pain of editing the model went up, but the pain of using multiple DataContexts went away, which lowered the overall pain drastically for them.

There is no point in making a data context for each business entity, you only need one datacontext per database.

well it depends on how many users will use your database simultaneously not how many tables are there. So its all about typical database issues: number of connections, locking and other stuff.

I now use 1 for the entire database, but there are legitimate uses for having more. For example, I run a script when installing my site that connects to a remote DB and imports and converts data to the new format for deployment. The process uses some temporary tables.
By putting the temporary tables in a separate context, once the site is deployed I can simply delete these contexts and code as they are independent entities.