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 ...
In my opinion: yes they are, and yes you should.
They give you confidence in the changes you make (everything else is
still working). This confidence is what you need to mold the code,
otherwise you might be afraid to change things.
They make your code better; most simple mistakes are caught early with the unit tests. Catching bugs early and fixing them is ...
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 ...
Just Tell him the truth.. You are not a PHP shop. (That's reason enough why YOU can't do it in PHP)
This is the price you are quoting for .Net. If he can beat that elsewhere, so be it.
It's a horrible sales tactic to knock down your competition based on the platform used. (Even if it has a lot of weight in the clients mind)
Sell yourself, Sell your ...
The concept behind unit tests is based on a premise that has been known to be false since before unit testing was ever invented: the idea that tests can prove that your code is correct.
Having lots of tests that all pass proves one thing and one thing only: that you have lots of tests which all pass. It does not prove that what the tests are testing ...
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 ...
If you've ever seen the benefit to writing a main method to test some small piece of code for school, unit testing is the professional/enterprise version of that same practice.
Also imagine the overhead of building the code, starting your local web server, browsing to the page in question, entering the data or setting the input to the proper test seed, ...
Unit testing has something of a mystique about it these days. People treat it as if 100% test coverage is a holy grail, and as if unit testing is the One True Way of developing software.
They're missing the point.
Unit testing is not the answer. Testing is.
Now, whenever this discussion comes up, someone (often even me) will trot out Dijkstra's quote: "...
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 ...
This is an answer that you will see a lot of when it comes to software development, but the usefulness of unit tests really depends upon how well they are written. A nominal number of unit tests that check over the functionality of the application for regression testing can be quite useful; however, a plethora of simple tests that check the ...
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 ...
Again, this is only for my plant, and I'm the only one who will ever be supporting it unless I leave the company, and then my replacement would be supporting it. Not someone else already in the company.
1 -- Don't Assume you're the only one who's going to support this. You do like your sick time and vacation, right? What if you need to take extended ...
Projects done for university classes differ vastly from business applications you'll write at your work. The difference is lifespan. How long does university project "live"? In most cases, it starts when you write first line of code and ends when you get your mark. You could say that, effectively it only lives for the time of implementation. "Release" is ...
Generic repository is even useless (and IMHO also bad) for Entity Framework. It doesn't bring any additional value to what is already provided by IDbSet<T> (which is btw. generic repository).
As you have already found the argument that generic repository can be replaced by implementation for other data access technology is pretty weak because it can ...
Welcome to one of the hardest problems in non-computational programming - properly representing dates and times to end users.
Realistically, timestamps should be stored in a fixed single representation regardless of how they will be interpreted, because no matter how hard you try, you will always have ambiguous cases, and you can't resolve them without a ...
You're overestimating the importance of source code, and underestimating the importance of everything else in the value chain of selling software.
Sure, a contractor might steal your source code. But what then? Will they be able to create a release, maintain the code further, contact your customers and sell them a knock-off for a lower price? Almost ...
This problem is the JIT compile. The application pool needs time to build the libraries before it can begin processing them. This can be sped up by using a warmup script, but it's something that needs to happen. It also depends on whether you're using a website or a web application project. A website is JIT for every page so the very first hit is slow and ...
You're probably wasting your time. If the prospect is considering a $10-15K job and having difficulty choosing between a professional firm versus "a guy," he probably doesn't actually have $10-15K. (If he was considering retaining your professional services firm using ASP and another professional services firm using PHP, it would be a different story.)
This is not a direct answer to the question, more of an expansion on it.
When you launch a new app I recommend logging everything the user does: log in, log out, scratches their a**, everything. If it's web-based, consider using heat maps so you know what their mouse was doing.
When I was on the BravoX project at Xerox in the late 70's we recorded pixel-by-...
Customers/clients, in general, do not care about code or technology.
If they did, they probably wouldn't let someone else make decisions on what technology to use for their business solutions. This applies to MVC, web forms, Rails, etc..
What they care about is getting a solution to meet their needs on time, and under their budget.
The ones who should ...
is writing unit tests for ASP.NET webforms something that is done often, and if it is: how do i resolve the "dynamic environment" issue ?
It is not often done. Working with UI elements isn't what unit tests are good at, since there's no great way to programmatically verify that the right things end up on the screen at the right places.
Would you guys ...
The answer to this question is completely subjective. The length of time it takes a developer to come up to speed can depend on:
the developer's level of knowledge and professional experience
the level of complexity of the application(s) or the level of documentation for the same
the ability of current application "experts" to onboard new developers. By "...
The controller and the ViewModel differ in various ways.
In MVC the Controller knows the view, it can change the View. It also knows the Model and can call it. In MVVM a ViewModel is an abstract representation of the View and does not know the concrete UI, it wraps the Model in a way so that it can be displayed as desired.
In classical MVC, a controller is ...
One reason is security - if (haha! when) a hacker gains access to your front-end webserver, he gets access to everything it has access to. If you've placed your middle tier in the web server, then he has access to everything it has - ie your DB, and next thing you know, he's just run "select * from users" on your DB and taken it away from offline password ...
When you start a project and have a particular need, you have a choice:
Either you implement your own solution from scratch,
Or you use an existent library or framework.
When implementing your own solution, you introduce several risks:
The needs may evolve, requiring you to constantly write more and more code. Ultimately, the code you've originally ...
You have a bigger problem than the readability. It looks like you don't understand how object initializers work.
Let's create a disposable class which traces its execution:
public class Demo : IDisposable
private string hello;
Debug.WriteLine("The parameterless constructor was called.");
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....
Here is a good litmus test:
Can you build a cookbook application?
At its core, a cookbook application is a CRUD application. This means it includes web pages which:
C reate data.
R ead data.
U pdate data.
D elete data.
To do this (without an out-of-the-box CMS of course ;), you must implement a fair amount of C#, SQL, XHTML, and CSS. This would be a good ...