I am currently working on a project of mine using Prism (the Composite Application Library/Guidance). The application will be a specialized MSPaint-like application for basketball (predefined objects for balls, players etc.).
Now I am wondering how to go about organizing my application into Prism modules. Especially when thinking about the drawing part of the software.
Should I split the general drawing view (2 columns: toolbox, canvas) in 2 modules (toolbox and canvas) or would the overhead created by the constant communication of these modules be too overwhelming?
How fine grained should Prism modules really be?
Thanks in advance and best regards,
crischu
There's very little overhead when you separate into modules.
I would go with what helps you organize your solution, rather than worrying very much about performance considerations. You can easily combine modules if you find they are causing you trouble or you are finding that two modules really belong together.
The rule is:
Make it run.
Make it run right.
Make it run fast.
In that order. Do what feels good first and refactor later if necessary.
I'd say it depends on how you distribute the functionality of your application over the UI. If you have just one screen, but with multiple sections that manage different features, each of that section (tab page, panel, etc) should have it's own module. This is the case with the StockTrader RI or NewsAggregator samples.
But on the project we are starting we decided to have multiple pages, one page for each major feature and to have navigation between them. In this case, a module will represent a page, nothing smaller than that.
Related
I am new to Sencha ExtJS and Architect MVC, but I know MVC and some other JQuery libraries in general.
I want to ask when building a real-world system, what is the proper approach to layout an Sencha app structure in Architect 2?
For example, we have the following departments in our app, they have distinct functionalities:
Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...
Approach 1: Write them in different Sencha Architect projects. Stitch up with master layout page + main area + header/footer + side bar pages. (using MVC.NET in our case)
--- Pros:
Multiple programmers can work on different sub-projects in an agile
environment.
Each project is smaller and easier to be upgraded or replaced.
--- Cons:
We have different Sencha Architect projects for, e.g. main areas, side bar, header, footer. How do they collaborate with each other? We now only use JQuery to pass information between them, but it feels kind of hacky.
Approach 2: Write them all in one big Sencha Architect project. So, it sarts up in a single app.html page with everything in it.
--- Pros:
Now every component in the project can collaborate with each other.
A true Single-Page-App All-in-One app.html looks nice.
--- Cons:
Having hard time if multiple programmers are working on one Sencha Architect project.
It is one big complicated piece of app. Although it is seperated into simple App, Store, M, V, C categories, but we can have name crash on components in a larger project.
Loading speed may be an issue? I am just guessing here because we don't know if Sencha Architect MVC design loads relevant windows and compoents part by part or everything together.
Question is, if we take 1st approach how do we make communications between different projects? If we take 2nd approach, is Sencha Architech 2 designed to build real-world projects that way? stacking everything in one big project?
First I'll say that your thinking about this problem in all the right ways. Your pros and cons are spot on.
Second for full disclosure I'm an engineer on the Sencha Architect team.
My suggestion is to have separate projects that are more loosely coupled and perhaps connected by a portal/dashboard application. The glue app can be written in anything including Ext JS in Architect.
The reason I say this is simply that I don't like putting all my eggs in one basket and if you've built single page apps you'll know that when they're working they really hum. But when an uncaught javascript exception occurs it can force that user to have to do a full refresh to get back to a happy state. Of course if you're perfect this will never happen :p Who's perfect?
I build Architect which is in fact a very large single page application. As a team we all do our best to keep each system able to work with as little dependency on any other system(s) as possible. We use things like eventing, pub/sub, adapter and plugin patterns, etc...
These systems are very much broken into separate namespaces and directories which like all software helps developers compartmentalize. Architect doesn't fully support this idea today. However with convention you can get close. e.g. HRController, HRNewEmployeeForm, HREmployeeGrid
Having HR as a separate app however, affords you HR.EmployeeController, HR.NewEmployeeForm assuming your app name is HR. Each app being a separate project also allows for the dev team to be more agile in how it deploys!! Major win.
Other users have taken this approach and one such user graphs all his projects together using a managed iframe approach
http://www.sencha.com/forum/showthread.php?243179
Asp.Net MVC is another good approach and might afford you some features like user auth etc...
Hopefully this helps!
I'm starting to build a rather big application in ExtJS Architect and I was wondering if it is advisable to split the application into multiple projects (to be precise projects as Architect defines a project)?
At the moment I am the only engineer working on this application, however more engineers may be assigned in the future. What would be the points to consider if you would to like to split up the project in smaller pieces or build one big project?
In addition: as far as I know it is not possible to 'share' a project in Architect over more than one developer. That votes in favor for splitting the project.
Disclaimer: I have not used Architect to build a project.
My thought on the matter is that if you are building an MVC project and you want Architect to manage your controllers and views you should keep all of it together. Especially if you have cross cutting communications between modules. However if you are 100% certain that your modules are completely standalone - meaning they have nothing to do with one another and might as well be separate apps ... (maybe they should?) ... then you could build them out separately and weave them back together after you are ready to ditch the architect. Remember its a one way street not an IDE. Bringing the modules together should just mean that the app.js now lists all of your controllers for all modules instead of just one for your module.
I downloaded Prism v4 and ran the installer. I went into the directory and ran the two following batch files:
Desktop only - Open Modularity With Mef QuickStart.bat
Desktop only - Open Modularity With Unity QuickStart.bat
When I compile these applications, I don't see any real difference. I've searched for MEF vs Unity and I've found some pros/cons, but nothing that specifically states whether one is "better" (and I know that is subjective) with use in Prism. I guess perhaps if I list my requirements someone can point me to the correct technologies to use (even if it's not Prism 4).
The application is to be written in WPF (NOT Silverlight).
The main application will be extremely thin.
The main application will use a Web Service to build the menu of the "apps/modules" a person has access to.
The "apps/modules" will be completely contained in other managed libraries.
The main application gets views and viewmodels by reflecting into these DLLs.
The main application should feed in services for logging, etc. into these "apps/modules".
For example:
A basic user might have the options of:
ViewOnly Address record
All items Address related are within Address.dll.
An advanced user might have the options of:
New Address record
Open Address record (update/delete)
Manage users
All items Address related are within Address.dll.
All items Manage related are within Admin.dll.
The app should not actually reference either of these DLLs, I plan to reflect into them so that if there are 100 different modules and a user only has access to 2 of them, only 2 of them are downloaded and used. Whereas a user that has access to 10 of them gets those 10.
I've already solved the downloading DLL via WebService. :)
None is "better": they are different things.
IMO your choice should be driven only by your requirements. Based on the requirements you posted here I would suggest you to use MEF, because you have modules contained in DLLs and the main app is unaware of modules to load. Those tasks are the reason that why MEF exists.
Anyway you could use them both: MEF for modularity and Unity to take advantages of dependency injection (testability, reusability, ...)
If all the modules are not recompiled at the same time as the app, then MEF gives you lots of ways to cope with changing interfaces in the main app. Otherwise MEF may be more complex then you need.
I've been using Unity over a year with PRISM but I've noticed some serious memory leaking issues. Hence I decided to give PRISM 4 and MEF a go. What I've done is firstly converting my app to use PRISM 4 with Unity. Then I converted a branch to use MEF.
It may sound funny but MEF seems to handle memory consumption and release somehow better than Unity.
Would be nice to hear whether others have made the same experience?
Regard to your question whether MEF and UNITY can work nicely with each other, i can tell you that they are working really well with each other. I have developed a proof of concept application which used PRISM, Unity and MEF.
I am developing a silverlight application for the past 6 months using prism framework. When I look at the code base now it has grown huge with lots of modules, event aggregators, inter module communication code etc. On hindsight I am contemplating whether I made the right choice. Is there any other simpler framework I should have gone for ?
Prism is at its best when targeting a large application. Why? Because the core concepts Prism provides, such as Modularity, UI Composition, support for MVVM, etc. are used the most in this kind of applications.
The idea, as you said, is that you are likely to end up with a bunch of modules. The benefit of that is that your application is decoupled, and modules can be tested in absolute isolation so they are easy to maintain.
By using Prism, or any other library/framework that modularizes your application, (correctly) in large applications, you don't need to go through your entire application looking for bugs when you make a change to one of the parts. This is not true in monolithic applications, where making a minor change might bring down the entire app.
Another plus for Prism in this scenarios is that it allows multiple teams to work on different modules simultaneously, without affecting each other's work. This is specially useful when working with distributed teams.
The thing that would convince you of making the right choice, would be comparing the application you created with the same one but with high coupling of its components.
I hope this helps
Couple of year ago I when to work for company as web developer. It has my first Sirius web development job, (ASPx/C#) so it has very exciting and I learned a lot about that world, from the developer point of view.
In that group we had a concept for the pages where loaded in the page UC’s (User controls), I don’t know if it’s the same in every web development team with every language, I’ll assume it is so.
The contract ended and I came back to develop win32 “winForm” application.
But since them I have tried to apply the same principle for my win32 development I learn there, meaning having bunch of UC’s (Visual User controls) that I load in the form.
They are regular visual components, not loaded in the toolbox, code is available in the project, but the component is not developed in the form, they are loaded there.
I would like to know opinions about this approach, what other are doing similar or better to this And improvements that can help us to speed up development and increase code reuse, because that is what this is all about.
If you're using the layout components in Winforms, this might be an acceptable approach although I think the thing that distinguishes the web and Windows Forms (note: NOT WPF!) is that in the former you do a lot of "compositing" which is why the UserControl concept is so useful whereas in the latter you operate on very sophisticated controls (e.g. 3rd party - in my last gig we used an incredible grid control via a small company called Infralution)
The main problem I would see is with layouts since the rendering model is a little different than the web. I know nothing about your application but if it "works" that is what is most important. I assume in this case you use things like the FlowLayoutPanel and the TableLayoutPanel properly.
If you want to go a more canonical route, take a look beyond simply creating components at how you can use the inheritance model to composite your application in a more robust way - having a base Form class that has containers for where your "UserControl" type components go and then using some kind of interface based dependency injection to swap them out while the application is running.
Finally, take a look at some of the open source Windows Forms applications out there to see if you're being too hard on yourself since common UI and reusable components are a goal in every application. Even though I've always thought Microsoft's Patterns & Practices stuff teetered towards being bloated, there are some good ideas and you should study some of the approaches of the Composite UI Application Block they put out.
Okay, not finally, there's one more thing I'd like to add: take a long hard look at WPF which will bring back a lot of the concepts from your web development days and give you that kind of power in a desktop application.