[...]u We like the points that this web blog has. Enjoy this wonderful sunday eve p2[...]…

My comment was intended to go under the Guid discussion post, but I must have not had enough coffee when I posted.

Thanks for the reply, it makes perfect sense. The only thing that I wonder is how else you would select something like a conference when the PK value is all that would provide you a sure unique value to select by? For Employees I can see the client having their own HR unique key for each employee that you can use, 1) because the employee is likely to know their employee number and 2) doesn’t expose the PK as you say. But what about entities that are created only in the software? I know you leveraged an Employee service to get the currently logged in user, but what about editing the details of a skill type? Would you not expose the PK to the Edit Action in order to get back the values for the form?

This is an interesting observation, but not one that has crossed my path largely because I consider exposing PK values to users to be a pretty big anti-pattern (e.g., one of the reasons that GUIDs are ‘acceptable’ to me as PK values is that I don’t EVER want my users to see them under really any circumstances). In the synthetic- vs. natural-PK database design debate, I come down pretty strongly on the synthetic side, meaning that PKs never have any semantic business meaning to me.

In a URL, if (as you quite correctly suggest) its often valuable to expose some business meaning-value, I would *still* permit the user to see Controller/Action/4 but in this case ‘4′ would *never* be the PK of the thing I wanted to list but would instead be the ‘customer number’ or some other value with business meaning to my users.

IMO the canonical example of an exposed MVC URL of the form Controller/Action/id is a horrendously poor design decision to expose the PK of your records to the user of the system. PKs are an implementation detail that shouldn’t be exposed to users. I don’t mind seeing Controller/Action/4 at all as it can make the app easier to navigate, to link to, etc. but in this case ‘4′ would never be the PK value.

I seem to recall from memory that in this series of screencasts, I *was* exposing the PK as part of the URL at the early-stage design of the app (largely b/c it made testing it simpler for the time being) but by the end of the development cycle, the URL would certainly be adapted such that the ‘id’ part of the routing definition wouldn’t be the PK of the record in the DB.

Hope this makes sense and helps clarify my (eventual) intent with that approach.

-Steve B.

One of the pieces to this conversation that might be more trivial, but relevant none the less, is the use of Guid’s in the url. You no longer have Controller/Action/4, but Controller/Action/44444444-4444-4444-44444444. The logical URLs in the MVC pattern are one of the positives in my opinion and this complicates it. Would be curious to hear your opinion on this.

Regards

Firstly, thanks for a great series on Agile so far - I’m looking forward to the rest!!

Its not directly related to your example application as I’m primarily focussed on Winforms appls, so I’m not sure if you’re going to be able to help me, but I am hopeful that you can give me a couple of pointers.

My question is around using Rhino.Commons with a Winforms application.

I’m a little confused - mostly because I’ve looked at various posts on this and I can’t find a clear answer.

With WinForms I presume I still need to do the IoC initialization, but I’m not sure where to place this in my code. Do I do this once i.e. in Program.cs or a base class, per form,etc??

I guess some of my problem is following a screencast designed for a different application architecture. I’m also very new to NHibernate and have never used Rhino.Commons before. Not to mention I’m looing at agile for the first time.

Well there you go. Thanks again for the great series and I appreciate any advice you may be able to offer.

Hi again. I didn’t watch the last screen cast. My notebook is broken ;(. I am not sure if you included the SEO part in the new video lesson. I want to add something and this is the multi-language support. So what do you think about the constructing URLs for different languages? May be a custom routing. I think it is important for SEO the multi-lang support to comes from the URL. Do you have experience about this? Can you talk about Multi-lang and SEO or post some static guide?

Thank you.

Thanks for the clarification. I agree that it is VERY nice that Rhino allows you to choose how in your face the UoW is.

Thinking further on this, I can see your point about why being as explicit as possible with Flush() is probably a good thing…and certainly there are times when you would want to flush the transaction before the end of the request.

(That said, I’m glad that you are planning on looking at this further as the series progresses. :D)

You are indeed correct that there are several implementation patterns for the (Rhino)UnitOfWork and I have shown but one. Rest assured that before the application is complete, we will have bumped into the need for several (if not all) of the others that you mentioned (including the With.Transaction(…)

In general, I prefer to be explicit about when I intend to flush my UoW within my controller methods rather than just letting the ‘ambient’ UoW handle it per-request. This may put me at odds with most Rhino users, but I’m ok with that

I usually find that while at first glance it may seem that this is ‘noise’ in the body of the controller method as you suggest, I think that the UoW (at least in re: when its flushed, etc.) is more of a business concern rather than a persistence concern and so I don’t ‘mind’ it appearing in my controller methods. It also makes the code easier to follow for anyone reading through it and provides a simple extension-point in the code should there be a need to change the implementation to start a nested UoW rather than simply hook into the ambient HTTP-request parent UoW (e.g., the originally-intended ’scope’ of the UoW is already delimited by the using(…) block).

As you say, there are actually many different ways to use the Rhino UoW abstraction (frankly that’s one of its strengths IMHO) and which one you choose is *sometimes* largely a matter of personal taste. For example others might look @ the controller methods and say “I would prefer that even the fact that there IS a UoW is abstracted away from me” and in this case you can simply use the ambient UoW without explicitly invoking it.

Hope this helps clarify a bit,

-Steve B.

I have a couple questions about how you are using the Unit of Work in your controllers. (EmployeeController line 88)

- Looking at the code for UnitOfWorkApplication, it seems like a UoW is started at the beginning of each request, and disposed at the end of the request. Given this, would you still recommend always explicitly calling UnitOfWork.Start() and Flush() within the controller methods? I can see that these explicit calls communicate intent, but for simple things they also seem to add a bit of ‘noise’ to the code.

- I noticed that Rhino provides a couple other ways to do things within a Unit of Work - the With.Transaction((() => //do stuff); syntax and also a facility for using [Transaction] in castle. Would you recommend using either of these as alternatives to explicit calls to UnitOfWork?

Thanks again,
Ben

Thank you.