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;
Webforms vs. MVC seems to be a hot topic right now. Everyone I know touts MVC to be the next great thing. From my slight dabblings in it, it seems ok, but no I don't think it will be the end of webforms.
My reasoning, and the reasoning as to why webforms would be chosen over MVC, has more to do with a business perspective rather than what one is better ...
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 ...
I emailed Scott Guthrie, an MVC expert at Microsoft. And probably the most qualified man to answer this question. He was kind enough to reply:
"Different customers look for different programming approaches, and a
lot love WebForms and think it is great. Others love MVC and think it
is great. That is why we are investing in both. "
So, to me this ...
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 ...
Generally, you want your Controllers to do only a few things:
Handle the incoming request
Delegate the processing to some business object
Pass the result of the business processing to the appropriate view for rendering
There shouldn't be any data access or complex business logic in the controller.
[In the simplest of apps, you can probably get away with ...
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 ...
I recently switched from using in-line SQL queries to using EF and here's what I've found:
Much faster to build the DAL (love not writing the SQL queries!)
Much easier to maintain
No longer need to remember to parse my input before building an in-line sql statement, which means less chance of a SQL injection attack (of course, it's still possible ...
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 ...
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 ...
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 ...
Stateless means that HTTP doesn't have built in support for states; e.g. you can't store if a user has logged in or done something else.
The most common solution is to use sessions to overcome that problem. This means that you have to be able to include a session identifier in each response or request. This is either done by creating a session cookie or by ...
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 ...
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 ...
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 ...
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....
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 ...
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 ...