ASP.NET - Final Year Student Project Dilema ?

[MTonez2014]

Okay I was petrified of posting this under the 'ASP.NET' thingy place, because the question itself is not based on actual code and problems encountered.

The question I wanted to ask was this:

In industry today, is there really a big fuss made out of whether one adopts the 'in-line' coding practice over 'code-behind' ?

i'm writing a piece of software, which will ultimately be webdriven - so I chose asp.net as my technology platform.

As i'm not and 'expert' programmer, I am limiting myself to 'in-line' coding , whereby the connection strings, form actions occur all one one page.

i have difficulty grasping what people mean by 'separating logic from presentation' and gave up on the whole 'layers' thing, as it was unnecessarily confusing the average guy like me. Sometimes I just wish they told you stuff in a no nonsense manner, that way the 'common man' would 'get it'.

So, should I adopt a 'code-behind' approach to writing all my .aspx pages , and if so - will lecturers/members of the academic staff pick up on that and award me extra marks ?

or since im not building a system for a big company, and its just a standalone solution (prototype) for a client of mine who needs a tool to aid him on decision making, could I not simply keep it simple and use 'in-line' code ?

asp.net wizards, those in industry, fresh graduates in the comp science discipline etc - please get back to me on this one

[Frinavale]

I don't think there is an industry standard for these types of decisions. It's all going to depend on the standards that the company has set to use. Since you are the company in this case, you can chose to what you wish.

Separating the VB/C# code out of the ASP.NET pages and into layers gives your application flexibility. There is a definite advantage to keeping a clear distinction between the UI and the logical code that drives the application. It took me a while to see the advantage of this too.

If you keep your code separate in layers (for example the user interface layer, the business logic layer, and the data access layer) it makes your application a lot easier for testing. If you implement each layer separately in such a way that it doesn't depend on another layer you can test things much more easily.

For example, you have a Data Layer. The point of this layer is to manipulate data in your data store. You can implement this component and test it to make sure it works before using it in another component. For example you can use unit tests to make sure that you can add things, edit things, and delete things in your data store.

Now you have a business layer. This layer contains the business logic for your application. It's layer that makes logical decisions based on user input and data from the data store etc. If this layer is kept separate from the Data Layer and the User Interface than you can also test it more easily...you aren't tied to using a web interface to test this component. You can test it using any tools you want to use.

Now you have the user interface layer. This layer can be very complicated. Sometimes you need to use JavaScript and Ajax in your user interface along with CSS...any of these things can cause bugs that may make your application unusable.

If you are trying to debug a problem it can be very hard to track down the cause especially as applications grow in size and complexity. Keeping your layers separate can let you test each component separately to find where the problem is happening. You can't do this when everything is merged together into the ASPX code.

Not only does it make things easier to test but it also wraps your code into clean, clearly defined tiers so maintaining this code in the future will be easier. If you changed the name of a table you don't need to go looking through each page in your ASPX page to make the change in your code...you just make the change in the Data Access layer. If you make a business logic change, you don't need to be looking through code that also connects to the data store...you just go to the business layer and make the change there....

Say you change out the database for an XML file!
Now you just have to change 1 component: the data access layer...the rest of the project doesn't get touched by the update which means there's less chance of breaking something else in the process.

Or say you want to provide an additional view for your website that is targeted towards mobile devices. If you keep your UI separate from your Business Logic and your Data Access logic then all you have to do write new web pages that link into the existing Business layer...instead of having to re-write your business logic for the mobile version.

Also, by separating your application into layers, it gives you the option have multiple people working on the same project at the same time. You can have a web designer working on the user interface, a database expert working on the data access layer, and another software developer implementing the business layer. Each person can use their own unit tests to ensure their part is working before adding it together into the completed project.

There's a lot of benefits to keeping your individual layer separate!

-Frinny

PS I moved your question to the software development forum since this is more of a software development question than anything else.