1) SessionManager from Xtensive.Storage.Web.
If you don't know, this is an IHttpModule automatically providing Session for each web request. More details are described here.
But to consider this part completed, it must be extended to automatically attach a DisconnectedState to Session provided by it for a particular web request. This feature might be quite useful for long-running transaction scenarios - e.g. wizards, where actual database modification must be performed only on the final step, although the data is updated during all the steps there.
I'm thinking about the following syntax:
- TData SessionManager.Demand().GetDisconnected<TData>(string key = null) where TData : class will attach cached DisconnectedState and deserialize cached data (of TData type) after doing this. If result of this call isn't null, it will be serialized & placed back to cache on successful completion of transaction.
- SessionManager.Demand().SetDisconnected<TData>(string key = null, TData value) where TData : class will set the specified value. If null, the cached one will be removed.
2) Validator control (of course, server-side only) that automatically validates version of a particular object (i.e. performs an optimistic version check).
Not sure to which control these validators must be attached - probably, they must be attachable only to our special invisible controls identifying the object.
Any ideas are welcome here.
3) Paging helpers.
Actually I'm absolutely not sure if this is necessary at all - there are plenty of paging examples for LINQ like this and that, and any of them must work.
So may be we must just add something like IQueryable<T>.Page(int pageSize, int pageIndex = 0) extension method with its LINQ translator forwarding it to .Skip(...).Take(...) sequence? But AFAIK all the grids for ASP.NET that support LINQ are capable of adding this sequence automatically.
Thus... May be we must just show a sample here? Again, any ideas are welcome.
Please leave your opinions and requests in comments. The similar post for ASP.NET MVC will appear shortly.
Two other ideas, not sure if they fit in this library
ReplyDelete- dynamic search form (build dynamic linq query from search form)
- make IPrincipal object available inside DO Session.
1) dynamic search form
ReplyDeleteI think this must be implemented by someone else :) Btw, I was surprised there is no third-party control for this - I tried to find it. So possibly it's a good idea - to develop a generic one and sell it ;)
2) make IPrincipal object available inside DO Session
Let's leave this until security implementation. I'm thinking about providing extension methods to Session instead of extending it directly by security-related stuff.
I suggest SessionManager to be able to work not only in "transaction per request" mode, but with in manual transaction management also.
ReplyDeleteAnother recommendation is that it's not a good practice to keep one session for one HttpApplication (as it implemented now). In high loaded application I want to be able to open Session (db connection) and transaction for short periods, even shorter than http-request.
> 1) dynamic search form
ReplyDeleteThis can be implemented as separate practice project, since it is useful not only for ASP.NET applications.
A simple solution would be "Query By Example", like in NHibernate.
ReplyDeleteps. and here's a sample of query form http://devtools.korzh.com/eq/dotnet/
It was told million times already nevertheless I can't help to tell it once again. If DataObjects could work without active transaction then SessionManager and other things like that would not be needed at all. Let's face it, almost all helpers you are going to implement as Xtensive.Practices are needed to provide current Session and current transaction, aren't they ? I.m not criticizing the product I'm just trying to get it straight.
ReplyDeleteI don't see any serious problems with activation. I hardly had a chance to write a stuff like this personally during last few years of DO4 development, but now I feel I should do this further.
ReplyDeleteCompare PersonController code to e.g. DinnersController (you know who's the author of this code) - I'm ready to bet DinnersController actually does less (e.g. there are no version checks). 77 vs 215 LOC. Unit tests for controllers? Nearly the same case.
Conclusion... I'm leaving it for your own ;)
Well, I am not sure I understand why you started comparing the controllers, but PersonController is an interesting sample to discuss. Take a look at PersonModel used by PersonController, essentially it is just a POCO with fields manually loaded and saved to Entity. Would not it be better if Person entity itself did the same job ?
ReplyDeleteIt is recommended approach in ASP.NET MVC - I've looked up a set of samples there, and in almost all the cases they avoid to use entities directly. There are at least two reasons for this:
ReplyDelete1) currently it seems difficult to control population of all this data from POST fields for objects that have a bit different structure (i.e. entities);
2) the same is correct for metadata - i.e. it is possible to move out metadata declaration to another object, but even in this case you must leave an attribute on original object; but having two different metadata declarations (one for each view) is impossible in this approach.
I think the most obvious reason for creating a special view model for each view is clearness: since there is automatic scaffolding, you anyway need to declare something describing your form. Probably, this is good even if there is no scaffolding: at least you know exactly what's POSTed by the form.
I'm going to create an example without such intermediate object as well, but I really feel its presence seems a good practice.