Last post Oct 24, 2008 10:54 PM by Acoustic6
Oct 23, 2008 11:58 PM|Acoustic6|LINK
I've been following the storefront series for a while now. I'm particularly fond of how you actively respond to and even incorporate constructive criticisms into the project. My team has been working on a project,
also using MVC, and following a similar pattern. One divergence we’ve taken is in our project topology.
We’ve found that, for example, housing the model classes in their own library is more “consumable” and testable than having the model classes in the same project as the SQL data access objects.
It seems a bit awkward for a data model (which strives for abstraction) to in the same library as a SQL-specific concrete implementation.
Also, for code coverage purposes, we test our SQL implementations (or other “external” oriented resources like sending email) in a second unit testing project such that our core unit tests aren’t testing concrete implementations.
I’d love to see this project take a similar approach where projects/libraries/namespaces are specific, concise, and geared to their purpose only.
Thanks, and keep the videos rolling; you have a hungry audience!
Oct 24, 2008 02:41 AM|robconery|LINK
Hi Acoustic, thanks for your thoughts.
I don't know if I understand the reasoning for putting a model in its own class from what you've said here. In other words - what makes it "awkward" and less-consumable? Is there something you need to do extra?
In terms of testing your SQL Implementations - are you referring to Integration tests? Unit tests should *never* involve a database - testing logic should be confined to mocks or stubs - something that won't fail and that you have control over.
Integration tests should focus on "did I integrate this properly" and should have setup/teardown steps to ensure DB readiness. Code coverage isn't really a concern with respect to integration testing - unless I've misunderstood you.
Many people have suggested I split out more projects - but to be perfectly frank with you, that's just file operations and mostly aesthetic. In fact I was going to have everything in the MVC site, but it turns out (and I'll talk more about this later) that
I will be sharing functionality with another front end. If I didn't need to do that - it would all be one project.
It's a long-held belief by many that separating your "tiers" into different DLLs is the way to go. This is only true if you need to share functionality with other applications (in an Enterprise setting, for example). 90% of the time - this isn't needed;
especially if it's a single eCommerce store. Moreover, sharing functionality is usually achieved by using web services.
There are reasons to separate things in terms of projects (Testing, for example, needs it's own thing). But not for the notion of separation of concerns. I know this is going to sound like crazy talk to you :) but just think on it for a bit.
Oct 24, 2008 10:54 PM|Acoustic6|LINK
My apologies for not being clear; I shouldn’t have authored the post so late at night.
“Awkward” was a poor choice of words to suggest that you should split out more projects.
You’re right that in some ways it’s aesthetic. There are cases, perhaps from a purist’s point of view, that makes more projects appealing, though.
Let’s say hypothetically that you want to take on in-memory caching as a new repository, and you want to reference your model project in order to strongly type it.
Given the current storefront project structure, when you reference the Data project you import not only the models, but all the SQL implementations as well.
It’s aesthetic, yes, but it’s also more than the “consumer” (the other poor word choice previously) should care about.
I’m approaching this from the vantage of shipping assemblies to customers where less is better and aesthetics matter.
Aesthetics help assemblies be more self describing.
I was referring to integration tests in terms of SQL.
Our testing practice, because we tend towards aesthetics, approach 99.5% coverage with the exception of integration.
If your SQL classes were part of our model library, code coverage would take an unnecessary decrease.
We find the opposite in terms of sharing – 90% of the time our code is share across projects; sometimes services, sometimes via the GAC etc…
It’s depends on one’s particular experience as to the percentage of realized shared resources.
Having worked for 3 service-oriented companies in a row, I’m biased.
Thanks for humoring the opinion - makes us all better =)