• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 969
  • Last Modified:

Approach for Application Layers (n-tier) for Web Application

Hi All,
I will try not to duplicate the previous entries (sorry in advance for this post).

A little background. I am a total newbie to ASP.NET. I have previously been involved with Enterprise windows n-tier application using .NET 1.1 with a complex client-side object model talking to the business layer in COM+, hich in turn talked to the DAL. Scaled very well with amazing performance.

I need to author a new website using ASP.NET/FW 3.5/SQL 2008. The site is not overly complex but will need to scale to cope with (potentially) 000s of hits per minute.

Having been "out of the .NET loop" for 2+ years, seems like thinking around object model creation and data access have changed i.e. LINQ, WCF, Generics, etc.

My questions are, if you were starting from scratch...
1) Craft an object model which communicates with a COM+ business / DAL layer?
          a. Quite involved, time consuming but scales well. 100% stored procedures.
          b. Do you still use DataSet or is there something else now?

2) Use LINQ  can you COM+ it? What about when you need to do something really complicated in SQL (I have many times!)

3) Any other ideas!

I am researching like mad, just seems like every book, forum, article has a different opinions / approach. Just need one to aim for...

Help! Many thanks Ian.
0
ianmansell01
Asked:
ianmansell01
  • 6
  • 6
  • 3
  • +1
10 Solutions
 
b_levittCommented:
Welcome to the world of endless options.  Even as an experienced web developer, people were argue such things until they are blue in the face so there's no right answer here only pros and cons.

Good news is you can use much of your n-tier knowledge here with asp.net replacing windows forms as your ui tier.  

If you choose the more traditional business layer option, Com+ Services are still available thru System.EnterpriseServices and the ServicedComponent class.   Addmittedly, I abandoned EnterpriseServices when .net 2.0 was released and with it System.Transactions - with web projects you get an additional scale out layer with the ui (load-balanced web servers) so a physically separate application layer has never been a huge concern to me, so going with something to just give me transaction support was an easy decision.  The biggest kicker here is the stateless nature of the web but if you were already using com+ stateless might be what you're already used to.  I guess my point is that there's a good chance your middle teir methodologies might already be perfectly suited for the web.

Nothing's really changed on this side from a return object perspective.  You can still use generic containers like datasets or return a collection of custom dataclasses.  .net 2.0's Generics have made this a little easier (ie List<yourbusinessclass>).

From there you can consider some of the new stuff if you want to branch out.  Linq-to-sql is basically an ORM tool (not just linq as linq can query any collection).  I love it for smaller projects but not sure it's suitable for the enterprise.  For me the biggest concept is to get over the "separation of concerns" issue between the business objects and your dal.  Essentially they are one in the same here.  Trying to use LINQ-to-Sql in a DAL is a waste of time IMO.  Then again I'm not a perfect person to give you that opinion - I've gave up on a DAL a long time ago - db access is much simpler than it used to be, 999 out of 1000 times the app doesn't need to support multiple databases, and IMO with primary keys, check constraings, and triggers, the DB is already a very active part of the business layer.

For enterprise apps (and rumored to be an eventual replacement for LINQ-to-sql) is the new ADO.net entity framework.  I've not used it but the phrase alone might be enough to let you do some research.

Ok, that was more than I intended to type.  Let me know if I've created more questions :).
0
 
Mark WillsTopic AdvisorCommented:
LINQ is now encapsulated in Entity Framework (covering both Linq-to-SQL and Linq-to-Entities). Have a look at : http://msdn.microsoft.com/en-us/library/bb399572.aspx

It is certainly a way to go, but you can also follow the same old tried and true methods especially if already tightly coupled with a failry stable database.

Stored procedures do seem to be more popular than before, and could certainly call them using LINQ. But think it is more likely a LINQ way or using SQL explicitly.

I am a bit like you in so much as like to control the SQL for very complex processes, but then that is why you would use a stored procedure...

0
 
b_levittCommented:
Minor correction mark - LINQ-to-sql and LINQ-to-Entities is now encapsulated in Entity Framework.  All of the Link-to-?? technologies use LINQ to query a specific datasource (additional types include XML and Datasets).  LINQ by itself is just a set of extension methods to allow you to query anything that implements IEnumerable<T>.  I guess my point is I like people to know that they can use LINQ outside of querying their relational datastore.  This article does a nice job of separating the two and starts with plain-ole LINQ:

http://dotnetslackers.com/articles/csharp/IntroducingLINQ1.aspx
0
Prepare for your VMware VCP6-DCV exam.

Josh Coen and Jason Langer have prepared the latest edition of VCP study guide. Both authors have been working in the IT field for more than a decade, and both hold VMware certifications. This 163-page guide covers all 10 of the exam blueprint sections.

 
ianmansell01Author Commented:
Thanks b_levitt and Mark. Great responses...

I've had a digg around... the plot thickens. So the EF seems the right way to go.. but I only require SQL Server support for this application. Sorry to still sound a little dumb on this stuff... only looking at it for less than 48 hours.

1) Seems like L2S and EF do not support the new SQL Server 2008 data types?

2) So does LINQ / EF generate a domain model based on the database schema?

3) I will most likely be using Telerik controls for the main UI stuff... they seem to support LINQ L2S, EF and have their own O/RM tool called Open Access. Its getting dark in here ~;0)

Worrying: Vote of No Confidence for EF?
http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Choosing between ADO.NET Entity Framework and LINQ to SQL
http://blogs.msdn.com/wriju/archive/2009/03/08/choosing-between-ado-net-entity-framework-and-linq-to-entity.aspx

Tables questioning your requirements and what is supported in L2S and EF.
http://blogs.msdn.com/wriju/archive/2009/01/05/choosing-between-linq-to-sql-and-entity-framework.aspx

Many thanks for your rapid replies so far.
Ian.
0
 
CodeCruiserCommented:
Ian,
You may be interested in exploring the ASP.NET's new MVC (Model View Controller) framework. Here are some resources

http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx
http://www.asp.net/mvc/
0
 
Mark WillsTopic AdvisorCommented:
You are quite correct, you can use LINQ directly, but Linq-to-SQL is by far the fastest way of building a DAL if going down the LINQ route - maybe not...

My real point about EF was from .Net 4.0 it will the direction from MS for data access, so expect to see a lot more of it floating arounding. But it is early days yet, hence all the discussions ( and would hazard a guess that there will still be a few years of continuing discussions).

Anyhow... The www.asp.net site is very good and has good clean relevant examples whichever direction you take. I guess the morale of that story is there will always be a few different strategies. If you are concerned about speed and consurrency, then it does indicate to me at least (think I am meant to do one of those IMO thingy's), and my natural tendancy would be to create my own DAL using SQL and Stored Procedures directly.

ASP.NET tutorials : http://www.asp.net/learn/data-access/?lang=cs

LINQ example : http://www.simple-talk.com/dotnet/.net-framework/designing-a-data-access-layer-in-linq-to-sql/  (take note of the last paragraph)

MSDN lates Data Access discussions / tutorials : http://msdn.microsoft.com/en-us/library/6759sth4.aspx

And the MVC was used to write the codeplex site which has the source code available : http://www.codeplex.com/aspnet/Wiki/View.aspx?title=MVC&referringTitle=Home
0
 
Mark WillsTopic AdvisorCommented:
There is one other site (amongst many out there) that I tend to frequent and that is http://aspalliance.com/ has discussions, whitepapers, code etc. Might provide some further insights.
0
 
b_levittCommented:
Yeah sorry mark, I wasn't trying to nit-pick, just clarify.

Mark has some good examples and links.  The only one I don't like is the linq example.  I prefer Scott Guthrie's tutorials:
http://weblogs.asp.net/scottgu/archive/2007/09/07/linq-to-sql-part-9-using-a-custom-linq-expression-with-the-lt-asp-linqdatasource-gt-control.aspx

The other article describes exactly what I'm against - trying to use L2S as a dal layer below a business layer and further complicates things by using a very specific data context (limited to product).  L2S is definately a RAD product and trying to use it in a traditional model deletes it's power.  Of course that point is mute - if were talking about an 'enterprise' size projects L2S's usefullness is questionable (IIRC mark_wills agrees with me here) and it's about to be gobbled up anyway by the entity framework.

As far as the entity framework being something you want to use in your next app - it's too new to tell.  That alone might be enough reason not to use it (for now).  The vote of no confidence article is interesting, but at the same time very few products ever make EVERYBODY happy.  Some people hate L2S too, but it doesn't stop me from loving it on smaller projects.

Plus if you ask me data-centric software development right is in a transition period - with more push towards these entity models and orm mappers, there is more resistence in the community to try to adapt these technolgies into their development environment rather than use them to evolve their practices.   My point is your asking for advice in a strange time, so I think everybody is going to be reluctant to give it.

I think in the end you have to do what fits you best.  If you have a whole team of developers that are already proficient in com+ development, then a more traditional model might be best for you.  Standard data access with stored procs is simple and proven.  And if that's where you go, I would recommend standard asp.net webforms over MVC - webforms mimic the event driven model that you're used to (I'd only recommend MVC if you're very into TDD).  Once you have adapted to the nuances of web programming, then maybe reevaluate what your lower layers should look like.  Then again if you can afford the downtime associated with a completely new model from the ground up, that we'd all be happy to be coming to YOU for advice :).
0
 
b_levittCommented:
In the end I'm pretty much agreeing with marks' " If you are concerned about speed and consurrency, then it does indicate to me at least (think I am meant to do one of those IMO thingy's), and my natural tendancy would be to create my own DAL using SQL and Stored Procedures directly."  Like I said before, it's rare anymore for me to consider a completely separate dal layer, but I'm not going to get into that argument with a database guy :P.
0
 
Mark WillsTopic AdvisorCommented:
Kind of baited a bit with that L2S link from simple-talk, and yes, do agree.

Bottom line is (for me) there are advantages in EF for packaged software where the evils of speed, efficiency and concurrency are sometimes not the focus as much as implementation, systems integrations, deployment, flexibility, security and market "reach" are really more of a concern. That is where EF starts to make more sense, complex packaged software is often supplied with the caveat of "need a big (brute of a) machine" to overcome potential performance problems. Harsh, but really not too far from the truth if we are being really honest.

For in-house where speed, efficiency and general performance must surely become more the focal point, then I think some of those ASP.NET sample projects probably make more sense.

In terms of arguing DAL with a database guy... :) ... it is true, DBA's and Developers do not always see eye to eye in terms of Data Access, and developers sometimes need a bit of a guide ;)  But in all reality, using any kind of ORM approach you will find nuances dependant upon tool of choice in your database design which always makes me shudder just a little bit (yeah, suppose I am that database guy).



0
 
b_levittCommented:
"using any kind of ORM approach you will find nuances dependant upon tool of choice in your database design which always makes me shudder just a little bit"

I completely agree - until L2S came along every ORM I looked at never gave me a feeling that I was saving any work, only transfering effort from ansi standard sql and ado.net to some proprietary tool.  I'm still a strong supporter of plain ole ado.net access, but the idea that you need a separate DAL.Product.Save from Product.Save is thought that needs to be evaluated on a project by project basis and isn't simply a given.  I suppose I'm a little off topic - perhaps I need to start my own question on the pros and cons of a DAL ;).
0
 
ianmansell01Author Commented:
Thank you to you all... I know its a pretty open ended question. Thanks for the input. P.S. I've split the points..
0
 
Mark WillsTopic AdvisorCommented:
Thanks, and hope we were able to provide some benefits / thoughts for you. Certainly a lot to think about....

What is your current thinking ? Which way / what approaches do you think you will adopt ? Maybe you could pop-in again and let us know a bit further down the track ?

0
 
ianmansell01Author Commented:
Hi Mark,

1) Prototype using L2S (with SPs)

2) Actual development using hand-crafted object model / business services. I will author so I can migrate to COM+ fairly eaily if required.

I just know I will run into problems without having full control.. bit more code / effort but I know it will be fast / scalable / fit for purpose.

Cheers
Ian.
0
 
Mark WillsTopic AdvisorCommented:
Thanks Ian...  Tend to agree with step 2, but could be quite different from step 1.

Cheers,
Mark Wills
0
 
b_levittCommented:
I would say L2S is worthy of a look, but to get a handle on it, start with some simple data manipulation without SPs.  If you're going to use SPs for even the simplest DML, then I would agree with mark and go with 2.

.net's wrapper for com+ is System.EnterpriseServices (classes inherit from ServicedComponent).  However, if your only need for com+ is transaction support than use System.Transactions.  It's a lot easier and will work with your hand crafted methods OR L2S.  It's probably one of my favorite additions from .net 1.x.

Good discussion as usual mark.

0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 6
  • 6
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now