The single best reason to not use the repository pattern with Entity Framework? Entity Framework already implements a repository pattern. DbContext is your UoW (Unit of Work) and each DbSet is the repository. Implementing another layer on top of this is not only redundant, but makes maintenance harder.
People follow patterns without realizing the purpose of ...
Yes you should.
It not only makes your back end re-usable but allows for more security and better design. If you write your backend as part of a single system, you're making a monolithic design that's never easy to extend, replace or enhance.
One area where this is popular at the moment is in Microservices. Where the backend is split into many little (or ...
I developed ASP .Net WebForms applications for 3 years, and after one day of doing an MVC tutorial I was sold. MVC is almost ALWAYS the better solution. Why?
The page lifecylce is simpler and more efficient
There is no such thing as controls besides html controls. You don't need to debug your output to see what ASP .Net is generating.
ViewModels give you ...
Stateless - There's no memory (state) that's maintained by the program
Stateful - The program has a memory (state)
To illustrate the concept of state I'll define a function which is stateful and one which is stateless
//The state is derived by what is passed into the function
function int addOne(int number)
return number + 1;
I don't see any reason for the Repository pattern to not work with Entity Framework. Repository pattern is an abstraction layer you put on your data access layer. Your data access layer can be anything from pure ADO.NET stored procedures to Entity Framework or an XML file.
In large systems, where you have data coming from different sources (database/XML/...
You cannot possibly avoid building an API. Even if you build "just a Website", it will still need to get its data from your backend somehow. However you decide to do this, that is your de facto API.
Knowing this, the real question isn't whether to build an API, but how to build it. You can do it on-the-fly as an ad hoc thing -and indeed, many Websites are ...
stateless means there is no memory of the past. Every transaction is performed as if it were being done for the very first time.
statefull means that there is memory of the past. Previous transactions are remembered and may affect the current transaction.
You are conflating the Razor syntax with separation of concerns.
Separation of concerns has to do with how you structure your code.
Being able to use C# in views doesn't prevent that. It has nothing to do with separation of concerns as such.
Sure, you can structure the code in your view to not comply with separation of concerns, but what about C# code ...
I know microservices are all the rage right now, but they aren't always worth it. Yes, loosely coupled code is the goal. But it shouldn't come at the expense of a more painful development cycle.
A good middle ground would be to create a separate data project in your solution. The data project would be a .NET class library. Your ASP.NET MVC project would ...
Yes. FormsAuthentication is deprecated in MVC 5 and onwards.
At least, that's the short answer.
The long answer is that pre-MVC 5 traditional FormsAuthentication is still ok to use. It is, however being phased out in favour of alternative approaches such as ASP.NET Identity.
In Visual Studio 2013, the authentication options supplied for and MVC 5 ...
Here's one take from Ayende Rahien: Architecting in the pit of doom: The evils of the repository abstraction layer
I'm not sure yet whether I agree with his conclusion. It's a catch-22 - on the one hand, if I wrap my EF Context in type-specific repositories with query-specific data retrieval methods, I am actually able to unit test my code (sort of), which ...
This is a stale question with a lot of answers but none had the answer I would have expected to be listed.
The short answer is:
Use ASP.NET MVC if you intend to properly build a web application with modern programming conventions and industry embraced patterns for the ASP.NET platform. On the down side you will be expected to know how HTML and client-side ...
I'd like to say it's cargo cult programming, but there are technical reasons for this structure. Asp.Net MVC took a convention over configuration approach to nearly everything. By default, the Razor view engine searches the Views directory in order to resolve which view to return from the controller. There are however a few hacks to get a different project ...
private void Demo()
// Do something, given that the result doesn't matter.
public void Do()
// The following line will be executed without waiting for the result.
Note that starting a method without caring about the result or about exceptions it can throw is risky.
If an ...
I am a complete and total convert to ASP.NET MVC and have not looked back, that said I do still have to maintain several very large WebForms apps. Here's my take on it:
Use these when you have some serious heavy lifting to do with grids. The grid controls are really very nice when you have a simple dataset that fits nicely in a tabular format and ...
Rather than directly answer the question, my response questions the assumption made in the question. That is, the assumption that Razor was built for MVC is incorrect. I work at Microsoft on the ASP.NET team and have first-hand knowledge of this.
Razor did not start out as a view engine for MVC. It was created for ASP.NET Web Pages, which is probably as far ...
No you shouldn't. If you don't have immediate plans to create alternative frontends (like mobile or desktop apps or separate web application) which access the same backend, then you shouldn't introduce a web service layer. YAGNI.
Loose coupling is always desirable (along with high cohesion), but it is a design principle and does not mean you have to ...
Actually there is a push back in the .NET world against these very things you mentioned. In the first example you gave however, the routing engine is given a convention for mapping the default route. The very fact that the routes are dynamic make it nigh impossible to use a static configuration.
You also mention XAML/WPF, both of which were under ...
My company has one application built like this. Initially we were commissioned to build a back end with API for a front end that another developer was creating. When the other developer couldn't develop that front end we were commissioned to build the front end too. While there are definitely benefits to this approach there is a huge disadvantage: cost. The ...
You should try to meet two goals: Uniqueness, and usefulness.
Using a GUID guarantees uniqueness, but one day the files may become detached from their original source, and then you will be in trouble.
My typical solution is to embed crucial information into the filename, such as the userID (if it belongs to a user) or the date and time uploaded (if this is ...
As I understand it, asking for the Task's value in this manner will block code execution until the value from the awaited method is returned, effectively making this a synchronous call.
When you call await db.Departments.FindAsync(id) the task is sent off and the current thread is returned to the pool for use by other operations. The flow of ...
You've got a lot of moving parts in your question, touching on a lot of concepts, but here's my basic advice when it comes to how to think about a mid-to-large scale MVC application:
Presentation <---> Business Logic <---> Data Access
Firstly, it's best to not think of the the app as "an MVC application". It's an application that uses the MVC pattern ...
SOAP, REST AND PEOPLE'S CREATIVITY
SOAP needs a description document like WSDL because each resource can be consumed with different messages, there are no definition on the protocol about constraints to the possible names/messages that you can manipulate a resource.
For example, in SOAP your web service that allow clients manipulate an user can expose the ...
In my applications I have always separated things out, with different models for the database (Entity Framework) and MVC. I have separated these out into different projects too:
Example.Entities - contains my entities for EF and the DB context for accessing them.
Example.Models - contains MVC models.
Example.Web - web application. Depends on both Example....
There are times when doing a ToList() on your linq queries can be important to ensure your queries execute at the time and in the order that you expect them to. Those scenarios are however rare and nothing one should worry too much about until they genuinely run into them.
Long story short, use IEnumerable anytime you only need iteration, use IList when you ...
It depends on the type of application and the type of market you are in.
There are trade-offs and benefits to going this way. It is not a clear-cut answer that one way is better than the other.
I'll talk from personal experience. I was the one who decided to take the codebase that I work on in this direction back in 2007. That codebase is somewhere in the ...
I really hate that none of the examples show how it’s possible to wait a few lines before awaiting the task. Consider this.
Foo foo = await getFoo();
Bar bar = await getBar();
Console.WriteLine(“Do some other stuff to prepare.”);
This is the kind of code the examples encourage, and you’re right. There’s little sense in this. It does ...
This may look like a violation of the DRY rule initially, but I'd argue that "similar, and even identical, code" isn't necessarily "repetition" if it does something different or is able to change independently. And in the case of view models, the code is defining what the "client" sees, not necessarily the entities and operations the business talks about. So,...
This is like asking what the difference is between an apple and an apple core. These two architectures aren't replacements for one another. I think a more accurate view is that the 3-tier architecture augments MVC.
The MVC Architecture
Models: These represent "stuff" in your application. This layer has gotten a little fuzzy in recent years, as I will ...
The reason why you probably would do that is because it's a little redundant. Entity Framework gives you a wealth of coding and functional advantages, that's why you use it, if you then take that and wrap it in a repository pattern you are throwing those advantages away, you might as well be using any other data access layer.