建筑/设计模式问题

Question

So yesterday my mate and myself had this duscussion about the architecture of this e-shopping website that im developing. Note that I work with ASP.NET for this. He was quite surprised to learn that I do not keep the Items added to the shopping-cart in an ArrayList or other Generic list but rather i insert them straight to the database using LINQ To Entities. Could I pass only for this web app and not use n-tire or should I do as my friend suggested which is, have methods that perform updates, deletions etc.. I highly appreciate your feedback as this is a very important dilemma for me. Thank you!

Answer 1

I think there are two things to think about here:

One of the worst things you can do is over design, and create a N-Tier system when it isn't needed. If there isn't a need to have a Data Access layer, don't throw one in there.

Find out the demands on your system, if you have a need to be able to scale out then you are going to have to design your system in tiers, and use data access methods that are more scalable, as well as services to get/update your data.

Second, whether or not you should be throwing these things into a database, as the user adds things to a shopping cart. I don't think this is necessarily an n-teir problem. Trips to the DB are costly, esp when you could just store them client/session side until..

---

With that being said, I personally like to use a Data Access Layer, I find that it makes code cleaner, and it makes you standardize how you access and change your data. Instead of each class/method being able to change data adhoc, they have to do it through a well defined set of interfaces in the DAO layer that you can control, audit, etc. By using a DAO layer it also helps facility mocking, which is invaluable when it comes to testing.

References for N-Teir development:

1. First just understand what you are trying to accomplish!
2. What is N-Teir Architecture
3. Asp.net Tutorial
4. MSDN on Application Design (From N-Tier to .NET)

Answer 2

Let me make sure that I understand: As items are added to the shopping cart you're persisting them right away rather than waiting until the session is completed to do them as a single unit of work. You aren't concerned about transactions here, so you must have the session id and some kind of flag to indicate whether or not an item is purchased. When the customer indicates that they want to buy, your program queries for all the items associated with that session and updates all their purchased flags as a single unit of work.

Is that a correct summary?

You've made a choice of how to handle committing your shopping cart as a single unit of work. I think there's more than one way to do things, and your way is defensible.

But I disagree with the comment about over-engineering. A layered architecture isn't that difficult to construct. It centralizes your persistence logic in one well defined package that you can test separately and put aside.

There are a lot of virtues in the layered approach. All of development is a problem of managing complexity by partitioning large problems into smaller, more manageable ones. We use objects and packages to do this. I think it's a better approach as your system grows. It's one reason why client/server isn't as widely used as it was 15-20 years ago.