+972 52-548-6969
Taking a look at S#arp Lite, Part I
This is a review of the S#arp Lite project, the version from Nov 4, 2011.
I was asked to review this project a long time ago, but I never got around to it. I had some time and I decided that I might take a look and see how it goes. I don’t like the S#arp Arch project, because it seems too complex and heavy weight for the purpose.
The project comes with a sample application, which is good, because it is easy to see how the framework is intended to be used. Unfortunately, it is yet another online store example, I am getting heartily sick of that. On the other hand, it is a fairly simple model and easy to understand, so I grok why this keeps getting chosen.
Review Rule, I look at the code. If I wanted to deal with documentation, I would write some for our products. I am doing this because I find it fun to look at other people’s code. So skip any comments about “if you read the docs…”.
We start from the project structure:
I am not sure if I like it, I don’t know if I agree that all of those splits are needed, but this is well within reasonable limits, so I am willing to let it slide on the grounds that this is personal taste more than anything else. Looking at the dependencies, we see:
The Init project contains two files, which are responsible for… well, starting up, it seems. Again, I don’t see any reason why this would be a separate project, but that is about it so far.
Next in line is the NHibernateProvider project, in this case, we have the following:
So far, I am cautiously optimistic. All of the files / folders marked with red are actually all about setting NHibernate up, not about hiding it. But then we get to the read me file, which reads in part:
This folder contains any concrete, NHibernate-specific query classes.
There should only be classes in here for any respective query *interfaces* found in
/MyStore.Domain/Queries/This folder will usually be empty except for very exceptive cases.
This is… interesting. Can’t say whatever I agree or not yet. Looking at the QueryForProductOrderSummaries, we see:
Note the comment, there are better ways to do it, but we demonstrate an ugly way, and how to nicely encapsulate it.
That is enough for now, I think, next post, I’ll touch on the actual model…
Comments
Great, now we are gonna build frameworks on frameworks on frameworks. Next thing is a S#arp Super lite framework? Why make things more "complex" or depending. Most of the time the plain old MVC3 is better to maintain and/or understand.
@Wesley
True. The amount of time the .NET community spends on building frameworks on top of other frameworks is freaking ridiculous.
There is absolutely nothing in the query method that cannot be done without the framework.
Compared to all the other code reviews from ayende i read, this one is fundamentally different as it has nothing to criticise yet. Let's see how it goes
I've used S#arp Lite for some smaller projects, and liked it. Much of it seems to follow the principles Ayende writes about in this blog, so I wouldn't be too surprised if he likes it.
@Dmitry and @Roland: S#arp Lite isn't built on top of S#arp Architecture, it's a new framework where they threw out all the things that they considered bloat.
Sorry, I meant to address @Wesley and @Bob :)
@Per
There is nothing wrong with the design itself, its just that you have so much infratructure/vestige/plumbing before getting to the original business problem you set out to solve in the first place. For the context of "smaller" projects, you are going to be better off with rails, django or towerjs.
@Pete: agreed, I'd choose Django for a lot of what I do at work if I had a choice, but given that we're (mostly) a .NET team, that's not for me to decide.
I'd say S#arp Lite keeps out of they way more than most .NET frameworks I've seen.
Also, I'd take a simple sql query for that type of read operation any day of the week.
I like the Sharp Architecture project. I am following it from the begining and it is great tool for avoiding plumbing code. However, after SharpArch Lite project release I made a review of the original SharpArch framework code base and I was really stunned about the amount of addons and stuff in the orig. framework. So I see Lite as really neccessary. You can start with Lite and pick stuff from orig Sharp Arch in per case basis.
Simple question: why should I need a framework to "insulate" NH or any other OR/M I like? Do I really need a framework for the application infrastructure?
@Felice - In my opinion you shouldn't. Some people find ORMs complicated and think they need a framework to abstract it away and make it simpler. But it doesn't really achieve that.
@Felice try to work with young guys who start to work and after a couple of weeks they start to state something like "In the future I don't want to write code" (just to let you understand the passion) ... well with a FW you can AT LEAST try to let them use something different from stored procedure to get a list of customers :)
@Grava I agree in using framework, of course, but you can wire an app by wiring frameworksI mean, NH - NInject - Caliburn ( an example ) this is the framework of your app that can change for others app. This leave space for innovating per step, ie change the or/m use another GUI framework and so on. Anyway I don't think there is any framework injecting passion in people who don't like to code :)
Comment preview