I decided to try to document my adventures in designing this .com site from the beginning, so that others might see where I’m going and benefit from the wisdom of a group of vets at this sort of thing.
I’ve got an amalgamation of a lot of different knowledge but have never rolled it all into one before, and am looking forward to bettering my principles of application design & thinking about coding.
So far, here’s what I know I want:
Separated layers – DB, Data Access Later, Business Logic Layer, UI
Some sort of OR/M tool to help the BOL / DAL communicate
Some sort of unit testing (would like to be able to do TDD but for this time out, I think as long as most of the tough stuff is covered by tests, I’ll settle)
Some sort of mocking to make testing of database stuff easier, etc.
So far, here’s what I’m thinking in terms of how to do it:
DB
[LIST]
SQL 2005
(this won’t change, need to work within it)
[/LIST]
DB Layer
[LIST]
Stored procs in SQL 2005
Carry out the “heavy lifting” in the database
[/LIST]
DAL
[LIST]
C# Project in VS
commands that return data sets, etc.
References / uses stored procedures
[/LIST]
BLL
[LIST]
C# Project in VS
Business Objects mapped with NHibernate
References DAL to get information for objects, etc.
Does the calculations of the
does validation, etc.
[/LIST]
UI
[LIST]
ASP.NET Web Site (not web app – ease of deployment?)
Sends commands to BLL
Receives messages & UI back from the BLL
[/LIST]
Testing / Mocking
[LIST]
NUnit tests to cover it all
Not sure what mocking solution will work best
[/LIST]
Development IDE
[LIST]
VS 2008
VS 2010 RC if I can get the whole team on it. Concerned about backward compatibility.
[/LIST]
Okay, clearly I’m new at this, and clearly there are some mistakes in there.
What I need to know is, suggestions for how to implement it and road-bumps to look out for.
Current plan for implementation:
Partner is designing UI
I design BLL, doing OR/M mapping and adding DAL function as I go
Tests are written first (at least pseudo-tests on paper) in NUnit
Code is written until it passes NUnit style testing.
DB & Code are refactored as often as possible but shipping the code is a priority so there may have to be some refactoring sprints after the fact because I’m not yet solid enough recognize the code smells and do it as I go.
So…have at it, SitePoint. I’ll be happy to answer questions, take your advice, and document.
I’m happy to be the guinea pig, but remember, in this experiment, shipping the code is a huge priority, so we can’t dawdle too long.
I would suggest not using Stored Procedures in the database, as they for couples your app to that database and kinda defeats the point of nTier programming. And you will then not be making proper use of your nHibernate ORM.
VS2010 would be a nice option. .NET 4.0 is only available in 2010, so if you right it on that framework, then no, its not backwards compatable. But if its on 3.5, then you will not have a problem.
I do not use a mocking system, so I cannot give advice there.
I disagree. The bullseye has been on the Stored Procedures since L2SQL debuted. Listen, if you need to make a change, it is alot easier to make the change through Management Studio, then editing the middle-tier, also you would have to re-compile your code, which would suck if your site is live. SP’s get bad press, which it doesn’t deserve. I reccomend a hybrid approach, say, LINQ2SP, combining SP’s and LINQ. I will be using that approach for the next project. Finally, to each their own, but if it isn’t broke, don’t fix it.
Good Luck on your project, remember, the newest features are not always the best solution (Entity Framework).
Stored Procedures are the work of the devil. If you worked on my team you suggested Stored Procedures, you would have your commit rights removed! SPs are a pointless abstraction in 99% of application and adds another layer to be maintained. Using SPs is broken, very broken. What do you think you actually get from them?! Eventually, the SP has to map to a domain entity. So lets say you add a property to the entity, you then need to store that, so that’s a table column, plus you need to modify the SP for reading, creating and updating. So that’s 4 modifications, and you still have to recompile your app… oh, and deploy the code AND database table AND SP changes… how about versioning SP’s? Is that easily accomplised? And what’s to stop a developer putting business logic in the SP?
In this day and age, its totally pointless and counter productive to think of your domain from the data up. Your trying to solve a business problem, so think of your domain, your C# classes, in that context. Using NHibernate to map your domain removes the concerns with data access, and that’s how it should be.
Elitist, much? Guess what, have you seen the job boards, Yoda? At least 90% of the .NET jobs ask for T-SQL/SP experience… What was that again? Numbers don’t lie, people do. Maybe your team doesn’t like them, but i’m going for the vast majority of employeers out there, and the vast majority say they requires that skill.
Lot of high traffic website required middle tire caching, including SQL caching, it easy to managed cached in SQL server using Triggers/Stored procedures.
New windows Azure architect use lot of these techniques, specially when it comes to horizontal scaling (database shading)
I create most of my applications using the n-tier design outlined in ASP.net Problem - Design - Solution. I’ve integreated LINQ into this framework as well for a few apps but to be honest I’d rather just create the entity objects myself than have to feel my way through the LinkToSql classes. I’m not sure if that is right or wrong.
In the book the author explains why he made certain choices regarding his architecture (and he used SPs) so you can get an idea of the pros and cons of each approach. Before this book I had no idea how to design an n-tier application in ASP.net but now I can churn them out pretty quickly and this book is a great reference. The code is readily available, there is a forum dedicated to the book, and even a website that shows the end-result.
There is actually a new version of this book for ASP.net 3.5, but I haven’t picked it up yet.
Yeah, I also have that book. Reading that book solidify my decision to use a classic n-tier approach. However, I’m going to tweak the code that book used, and use LINQ2SP in the DAL, to avoid writing heaps of ADO.NET code. Just create a SP, access it with LINQ, and return the results to the BOL. If it works it works. Having said that, I haven’t picked up the 3.5 edition of that book, but I’m sure it has a much different approach, compared to the 2.0 version. The Forum and Poll chapters were epic.
Side note guys, WROX Pro C# 4.0 is available for sale! Personally, I’m going to wait for Andrew’s APRESS book to be release on the 15th, the guy is a God in .NET.
Pot, kettle, elitist in another shade of black. I’m no elitist but I will not use Stored Procedures anymore. Thats from 10 years of experience using them. They are truly a nightmare. The idea that they allow you to only have to make changes in management studio is laughable really. Most of the time it will be edit your SP, update your code, recompile and hey presto you have added another layer to your upkeep.
Every good .net developer will/should know T-SQL/SP because you will have to deal with them whether you like it or not and you should know T-SQl anyway. The main reason you will have to deal with them is because they have been used over and over again over the last god knows how many years and Employers looking for developers are probably still copying and pasting the same qualifications from their previous ad.
Most of what you have laid out in your list looks fine to me assuming you are developing a relatively simple application. If it is a large scale application that is very complicated and likely to grow after release with added features then you need to consider going beyond n-tier and looking at DDD in it’s entirety. Problem is though if you go DDD you need to look at nhibernate or wait for EF4 in .net 4 which appears more DDD friendly but I haven’t looked at it extensively.
You will no doubt disagree with me as you seem well set in using SPs and fair enough. This is just my opinion not elitism.
If wanting to avoid tools that caused massive pain in previous projects makes me elitist, then so be it. And the vast majority of job specs, as BrianOConnell, are copy and paste specs by either the employer or the recruitment company. But I didn’t ask about job statistics, I asked what benefits you actually get from them?
@lphy Caching with NHibenate is easy and transparent and requires very little configuration to get up and running. I can switch from the SysCache to NMemcached without a recompile.
@goober, sorry for hijacking your thread and trying to start a religious war, SP fans are fun
That’s a huge chunk of new stuff your trying to take a bite out of! I would highly recommend ditching the thinking about an n-tier application design. I’ve found doing so results in bloated, multi-purpose classes and a rigid design. I personally find thinking along the lines of an Onion Architecture (yes, it also goes by some other names) puts you into the frame of mind of flexible solution where your business domain rules the ship, and not your data persistence mechanism.
First, I would look at the ASP.NET Mvc framework. That takes you closer to the metal than ASP.NET WebForms, and will give you a more testable platform to build on. I would also get comfortable with the SOLID principles, developing an app with these in mind has the pleasant side effect of also being testable from a TDD point of view. Once your comfortable with that, I would then checkout out Sharp Architecture. I’ve never used it, but I know people who have and have only good things to say. This framework will give you a good base to learn on until you feel comfortable to create a testable Mvc app from the start. The biggest thing to get your head around is Inversion of Control and Dependency Injection, SA has this already setup too.
A disclaimer applies, I work on large applications, and these techniques do add to the complexity of the solution, but the ROI greatly out weighs this, especially when working with with a complex app and domain. And this is all from my experience, I’m happy to discuss any points of contention in another thread to avoid hijacking this one again
I have at least two huge applications started several years ago when lets just say I didn’t know as much as I know now. They started small and are now huge behemoths I would be embarrassed to show anyone the code to. My tendency now would be to assume any project will benefit from DDD, TDD, the Onion Architecture and so on unless I can be 100% sure it will stay small and simple.
Be wary of P&P, sometimes they don’t give the best advice and develop solutions in an ivory tower without taking a look at what’s being down outside of MS.
The onion architecture sounds interesting, but it also sounds quite theoretical. It’s one thing to say you are going to write UI code that is not dependent on the database. It’s another to do it. After all, if there is a field on the UI which corresponds to a field on the database there is a dependency, and I don’t see any way around that. But perhaps my thinking is too simple. I’d like to hear more about these ideas, but theorectical ideas of creating “inward only dependency” are just that without practical examples.
If I can change where the UI field is stored/read without touching any of the UI code then I would say that there is no dependency between the database - persistence technology - and the UI.
