For past projects(the last few have been web using asp.net mvc) we created a service that caches our reference tables(as required) to be used primarily for dropdown lists.
Now I'm working on a desktop application.An upgrade from vb6/sybase to vb.net/sql server
I'm trying out WPF.
I started down the same path building up my DAL. one entity for each reference table.
I'm at the stage now where I want to setup the business layer (some reference tables can be edited)
And I'm not sure if I should follow the same process which is to use ReferenceTableService to "manage" the reference tables.(interacts with the DAL, Controller)
This will be an application that sits on a share that multiple users run.
What's the best way to deal with the reference tables? Caching them doesn't seem to be an option. Should I simply load them as each user opens up a new form in the application? Perhaps using a "ReferenceTableService"?
In this case, the Reference Table Service is thin layer in the application. Not a process running elsewhere.
I haven't done much WPF (be interesting to see what the WPF Gurus think) but I think your existing approach is sound and I don;t see why you should deviate from it.
Loading up on app start sounds reasonable; you just have to think about the expected lifetime of a user session vs the expected frequency of changes to the reference data.
Caching: if the data comes from a central service you could always introduce caching there.
Related
I have a web application developed with JSF 2 and primefaces. The project has been frozen for months, but it's quite advanced, the whole application run inside the same container under glassfish, so it's a monolith.
My application has an user interface and its purpose is to offer them the possibility to organize urls to tutorials (any kinds) as cards, with tags for the classification, into folders. So any user has its own tree, they can make a research inside the other users's tree create a link on a file in their own tree, copy a entire folder, reorganize it etc.
Nowedays we hear a lot about microservices, Spring boot, Angular Js, react etc. I like to develop with JSF it's a great framework, but I'm asking myself about refactoring my application, at least the necessary parts into microservices, and if JSF is appropriate for that or if I should user other tools.
What I like for example with JSF is the facility to create views, its component approach, and how it handle the full cycle of a request.
For example with a simple folder creation form :
I have to choose the parent folder, so I can bind a research component to a backing bean that makes a research indirectly in my DB using a DAO ( in my app an EJB using JPA). That happens at the "invoke application" phase and refresh my form list with ajax at the end. When I submit the form I can also bind a converter to the research component to retrieve directly a Folder object, the converter uses also a DAO to retrieve the object that I need at the "Invoke application" phase to finish the job.
I also use validators to control different attributes of a new folder, usually I declare them inside my entity class (Folder, User ...) with annotations like #NotNull etc. Before I save the folder on my db, I also check the user rights to see if he can write inside the parent folder and so on. I do that inside the backing bean, so at the 'invoke application' phase, and return a faces message if anything happens wrong.
When I read about micro-services I see that you can use them directly inside a form using json for communication, so it seems quite different. For example if I have a micro-service for the CRUD operations of my folders, are the validators, the converters, part of the service or are they stand alone services ? And what about the security checks ? that kind of architecture is quite mysterious to me.
ps : English is not my mother tongue so be indulgent please :)
AngularJs is pretty ancient man :)
You have to look at the pain points to identify ways to tear down your monolith. Monolith pains are usually slow and painful dev cycle and difficult manual test phases. If you did the entire arquillian thing and have full continuouos integration with single button deployments, you've slain the beast the hard way. Not many braved this route. But if you're looking at mounting feature creep with code freezes and manual test cycles then yeah you kind of want to try to pull some of those features out into a service you can redeploy very quickly
I have a class running in a winforms app which uses EF Code First. The DbContext is created via DI through the class constructor. All works well.
The problem is the data being referenced is also being modified via a web site, using the same DI pattern with EF Code First, and the data changes are not being reflected in the context instance in the winforms app.
I can solve this by recreating the DbContext object in winforms every time I access it, but seems to be more of a service location pattern to me?
Is there a true DI technique to achieve this?
Or should I remove the context from the DI and use service location?
Were you not happy with the answer to your other question (http://stackoverflow.com/questions/7657643/how-to-force-ef-code-first-to-query-the-database) which suggested using Detach, AsNoTracking or Overwrite Changes?
1) Maybe you could pass an interface that has the ability to create a DbContext, instead of the context itself.
using(var context = _contextFactory.Create()) {
var entity = from table in context.Blah...;
}
The Create method could either create the concrete class itself (defeating the DI pattern a bit), or use service location to have one created for it. Not that nice, but it's better than embedding service location calls everywhere and still means you're controlling the lifecycle yourself.
2) Change the WinForm to read from a webservice run by the website, effectively similar to disabling caching.
3) Deep in the heart of MVC (well not really that deep) it is referencing the DI container directly and using it as a service locator to pass as arguments for newly created objects. Technically you could do something similar in WinForms, but it would need you to split your application up into little chunks (controllers) that don't have a very long lifetime. Maybe it's worth looking at some MVC/MVP frameworks for WinForms, although I found myself cringing at most I saw after a quick google.
The problem is the data being referenced is also being modified via a web site, using the same DI pattern with EF Code First, and the data changes are not being reflected in the context instance in the winforms app.
This is a problem with your expectations.
If your web service and window forms app are in separate processes, they won't share in-memory data.
If you want to sync their in-memory data, simply re-query in one context after committing to the database in the other. This is the same as trying to share data between different SQL connections.
I can solve this by recreating the DbContext object in winforms every time I access it, but seems to be more of a service location pattern to me?
If you want to recreate the DbContext repeatedly, you could use an abstract factory to allow manual re-creation of the object, yet allow you to inject the specific implementation into the factory.
This is not (necessarily) the Service Locator pattern, and you would have to ensure that you manually dispose your DbContext instances. I'd give you some example code, but different DI containers have totally different ways of accomplishing a factory pattern.
Or you could simply make sure that you commit your data on the web service side, and re-query the data on the WinForms app side.
I need to build an offline database application on WP7.
App is simple - it's about making orders from our clients, then translate it to main server (MS SQL).
Spend a days read about existing techologies - but I'am still confused. Which is right for that project?
Sync Framework.
Looking good, but as I understand - it provides single tables - no reference beetwen them. All the references I have to build on client side. Sad.
Entity FrameWork on server side.
And I have no clue - what can I use on client side. Is there a way to serialize entity object to Isolate Store, then restore it, and continue work with it? May be I can use Sync FrameWork, but scheme will become strange then - kinda one way.)))
Working with WCF & XML - most simple for me. A lot of code and conversion, but in this case I understand the data flow. In other view - I already have app with pure SQL-queries. I wanna be advanced. ))))
Using ext. databases (siaqodb for example).
Which one? siaqodb suppots "Sync provider", but it doesn't support references beetwen objects - so I have to build them by myself? Any gain? I don't know.
Is there another way to build such apps? Point it please.
If this has to be done offline, then I would generally use something like:
storing the minimal amount of the required data within isolated using a WP7 specific database like Sterling
using either a new REST or a new RIA/WCF service with objects/functions you define in order to provide the required data synchronisation
I think this is your option 3?
I've never really liked automatic data synchronisation. I just find it easier to code the sync and deal with the error cases myself - this is especially the case if your wp7 client app uses quite a small footprint of data in relation to the larger main server db.
I have a WPF application that loads modules into my application via prism / MEF. Each module will reference an assembly I created to house NHibernate functionality (Unit of Work & repository pattern). Now that I started on the first module, the following questions came up:
Is it common place to have an nhibernate session open for the lifetime of a WPF / windows application?
Would it be a good idea to share the nhibernate session amongst all modules or have each module create its own session?
It's my understanding that the session is lightweight, so opening and closing a session is not a problem... however, if I close the session then I lose the change tracking... when I call Save, and the object is the same as when it was retrieve, I do not want a query to be executed.
Do not have the session open for a the lifetime of a wpf/windows application. You will have performance and memory problems if you do.
It really depends how these modules interact. Are they separate systems, or do they need to work in tandem to do work. If it's the former, I would say that they shouldn't share sessions. If it's the latter, I would use some kind of session manager that can pass out the current session.
I am using LLBL Gen Pro v2.6 and am attempting to create a means of auditing changes made to the database. Now, I know that LLBL Gen has auditing built into it using AuditorBase and dependency injection. The question I have is; I need to track not only the stuff that LLBL Gen exposes as auditable, but also the User who made the changes. From what I've seen there isn't a built in way of gathering this information. Has anyone used LLBL Gen's built in auditing and determined a way to do this?
Wayne E. Pfeffer
I have used LLBLGens Auditing classes. Determining the user is really something that you will have to handle. There are too many variables for LLBLGen to actually do this for you. How are your users handled? Is this a winforms or asp.net application?
The best solution would be to store the UserId in a session variable or static variable depending on which is more appropriate for your application. In your implementation of the Auditing class you can just pull the UserId from its storage place.
Another potential solution would be to override the Entity Class or the Data Adapter classes and pass the UserId in to your save methods. However, this would be a lot more work.
In my WinForms app, I accomplish this by creating a custom IPrincipal and stick that on System.Threading.Thread.CurrentPrincipal when a user logs into the application. Then, I can easily grab that from inside my LLBLGen auditing classes.
We're also about to implement auditing of changes to the db, and have the same issue of adding the user_id to the auditlog. I can see you can do the pull-approach, e.g. fetchingn the user_id from the web session (we're building a web application), but this would completely mess up the layering of the application, as I see it!?
I.e. if the DAL pulls data information from the presentation layer (web session), I won't be able to use the DAL in other contexts?
Best regards,
--thomas