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.
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 am currently building a WPF application and have some system wide settings. Where is the best place to store these settings? App.Config file, Database or some other sort of XML file? (need to read and write).
My other issue is the application has two states (i.e. Admin Mode, Client Mode) and depending on the state the application behaves differently i.e. (Shut Down, Restart, Lock, Unlock etc.) This seems like a good case to implement the State design pattern... but the issue I am facing is that the running application is itself the context class. I am a bit confused... should I be implementing the Singleton Pattern? How is this best implemented?
In general it is often easiest to store application settings using the Settings page of the Project Designer in Visual Studio. These settings can either be stored per user or per application. Either way, they can be saved easily by calling:
Properties.Settings.Default.Save();
They can be accessed similarly:
Properties.Settings.Default.FirstUserSetting = "abc";
You can find out full details by taking a look at the Managing Application Settings page on MSDN.
Regarding your second question, I would recommend using the State Design Pattern. Unfortunately, I didn't understand your problem with that, so please let me know what your issue is and I will try to address it.
I have a software requirement like that:
An app run on window but this app can connect to server to get and use its file by user.
User A can Log in, View all his file from server, Create new file, Edit content, Upload, Share file, View share file of another user.
I usually use .Net framework.
So what technology should i used to resolve this requirement
I really need some advice helpful
Thank!!!
Based upon the comments, I would advice to go for a clean separation between your UI and application functionality.
This will allow you to build possible multiple interfaces ( Win8, Mobile, ... ) for the same application. For Windows environment and you are used to .NET I suggest you take a look at WPF ( Windows Presentation Foundation ). I'm sure you will find that some people already created pretty solid file managers in WPF. It could serve as a good base for yours.
Few pointers if you look at WPF, look on http://www.codeplex.com for frameworks that could ease your coding. (Caliburn.Micro, PRISM, ... ). A very popular pattern is MVVM, this will structure your code so you can easy adjust it in the future.
Further more I think you can get very far with the windows build in libraries to manage the files.
For the editing you'll find a nice challenge to do that in the application, the easy road would just be to let the user open the file from the application into it's proper environment ( e.g.: a word document in Word, excel document in excel, etc.. ).
To get sharing going, multiple options are available. I'm think of sending email links, in application notifications, etc... Sharing could also mean that you set certain permissions on those files. For this you could take it to the limit of domain security management ( talking to an active directory to get the proper permissions etc. ) or you could simple implement your own into your application and restricting it on that level.
I'm new to .Net and trying to learn things. I'm trying to develop a Prism4 WPF app with
Visual Studio CSharp 2010 Express Edition,
Prism v4,
Unity as IoC,
SQL Server CE as data store.
I've studied a lot(?) and infuenced by this and this among others, and decided to implement MVVM, Repository and UnitofWork patterns. This application will be a Desktop application with a single user (me:-)
So, I've created a solution with the following projects:
Shell (Application Layout and startup logic)
Common (Application Infrastructure and Workflow Logic)
BusinessModuleA (Views and ViewModels)
BusinessModuleA.Model (Business Entities - POCO)
BusinessModuleA.Data (Repositories, Data Access (EF?) )
BusinessModuleB (Views and ViewModels)
BusinessModuleB.Model (Business Entities - POCO)
BusinessModuleB.Data (Repositories, Data Access (EF?) )
My questions are:
Which projects should reference which projects ?
If I implement Repositories in 'BusinessModuleX.Data', which is
obvious, where should I define IRepositories ?
Where should I define IUnitOfWork and where should I implement UnitOfWork ?
Is it ok if I consume UnitOfWork and Repositories in my ViewModels ?
Instict says it is bad design.
If (4) above is bad, then ViewModel should get data via a Service
Layer (another project ?). Then, how can we track changes to the
entities so as to call the relevant CRUD methods on those objects at the Service Layer?
Is any of this making any sense or am I missing the big picture ?
Ok, may be I've not made myself clear on what I wanted exactly in my first post. There are not many answers coming up. I'm still looking for answers because while what #Rachel suggested may be effective for the immediate requirements, I want to be careful not to paint myself into a corner. I've an Access Db that I developed for my personal use at Office, and which became kind of a success and now being used by 50+ users and growing. Maintaining and modifying the access code base has been fairly simple at the beginning, but as the app evolved, began to fall apart. That's why I have chosen to re-write everything in .Net/Wpf/Prism and want to make sure that I get the basic design right.
Please discuss.
Meanwhile, I came up with this...
First off, I would simplify your project list a bit to just Shell, Common, ModuleA, and ModuleB. Inside each Project I'd have sub-folders to specify where everything is. For example, ModuleA might be separated into folders for Views, ViewModels, and Models
I would put all interfaces and global shared objects such as IUnitOfWork in your Common project, since it will be used by all modules.
How you implement IUnitOfWork and your Repositories probably depends on what your Modules are.
If your entire application links to one database, or shares database objects, then I would probably create two more projects for the DataAccessLayer. One would contain public interfaces/classes that can be used by your modules, and the other would contain the actual implementation of the Data Access Layer, such as Entity Framework.
If each Module has it's own database, or its own set of objects in the database (ie. Customer objects don't exist unless you have the Customer Module installed), then I would implement IUnitOfWork in the modules and have them handle their own data access. I would probably still have some generic interfaces in the Common library for the modules to build from though.
Ideally, all your modules and your Shell can access the Common library. Modules should not access each other unless they build on them. For example, a Customer Statistics module that builds on the base Customer module should access the Customer module.
As for if your ViewModels should consume a UnitOfWork orRepository, I would have them use a Repository only. Ideally your Repository should be like a black box - ViewModels can Get/Save data using the Repository, but should have no idea how it's implemented. Repositories can get the data from a service, entity framework, direct data access, or wherever, and the ViewModel won't care.
I'm no expert on design architecture, however that's how I'd build it :)
I would highly recommend you to get the Introduction to PRISM and Repository pattern inside Design Patterns Library training videos. They are great ones. Hope it helps
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.