I'd like to develope simple set of controls to display many sort of data and be useful in normal silverlight application and can be used in ASP.NET MVC2 application. Right now i have no idea how to link those tehnologies, but this isn't my concern right now - i just heard it is possible and i'll find out how to do that...
Right now i'd like to know how can i use my Model's classes in such SIlverlight class library. I've generated POCO classes in EF4.0 for ASP.NET MVC2 application. Everything works great, but now i'd like to use some of those classes - create silverlight's controls, some ViewModel classes and fill my controls with data passed from my Model, used in ASP.MVC's app, through ViewModel.
Everything should be tested in any simple silverlight's app and at the end i'd like to be able use this class library in silverlight app and in ASP.MVC 2 website...
Silverlight it's own runtime and in general you cannot mix normal .NET assemblies and Silverlight assemblies.
However, one option is to share the source code by linking the same source file to two projects that compile to the different runtimes.
Another option is to use WCF RIA Services where Visual Studio will code generate your model classes in the Silverlight project and there are also options for sharing code between tiers. You will also get a service to operate on the objects from Silverlight. The service can be built on top of EF4.0 with very little code.
Finally, Silverlight 4 and .NET 4 are in some cases able to share assemblies if certain criteria are met. See Stack Overflow question named Silverlight 4 Assembly Sharing Problem.
What you need to do is use shared code.
you do this by adding an existing file to a project. In the add file dialog there is a arrow on the button that exposes the add as link option.
the point of this is that you cna have 2 projects which target the different CLR's but contain the same code and namespace references ... you can leverage these to have code that works on both versions of the CLR very simply.
Its really quite powerful. I have one set of tests that can target both versions.
Of course you are limited to the set of common functionality but that is implicitly part of your requirements anyway.
You cna even pass the objects over a service and have them deserialise nicley into the other CLR. Kinda suprising how well you can use the symetry
I am currently using this for aproject and am achieving what you want and after a few hours of playing with really suprisingly painless.
regards
Related
I want to build an web application(ASP.NET MVC 6) that can add modules/plugins without having to rewrite my source code.
Already read about MEF and Areas but are not helping much.
Someone who has overcome this problem that can help me?
Depends on which part of the web application you are targeting.
1.If it's in the request pipeline you would make a Middleware package.
2.It's it's in HTML you would make a TAG Helper package.
3.If it's an intrinsic functionality you would extend appropriate classes and throw them into a package. An example of this would be helpful extension methods or methods to add claims given a claims principal.
4.If you want to go even further you could create your own Visual Studio templates that you can use to pre-fill your options upon creation.
or "How to decouple UI from business logic in Delphi?"
Each target platform has its own set of native firemonkey controls (Windows=VCL, MacOS=TMS mCL, Android=D.P.F, iOS=TMS iCL and D.P.F). The new FireUI (multi-device form designer) is a great solution for styled components, but not for native components because it still requires the same component on the master pane to support all platforms. As you cannot mix them on the same form, it completely breaks the whole idea with Delphi.
A lot of developers would say that Delphi is the broken approach, see "Why FireMonkey is so fundamentally wrong in every aspect". However, the premise for this question is NOT to argue against Delphi, but to get the best results out of what it does offer.
The conclusion is then that for each form in your application you have to make a separate form for each target platform. This leads to these questions:
Challenge 1: How to include different form files in your project depending on your target platform?
Solution 1: include all of them, i.e. MainForm_IOS.pas, MainForm_Android.pas, MainForm_Win, MainForm_OSX.pas, and then use compiler directives inside the files, so only the content of one of the files is active. Disadvantage: a large application can have many forms (we have around 40), so we are talking about a large number of included files.
Solution 2: Do not include them in the project, but instead just place them in seperate folders. Then you can add the matching folder to the search path for each target platform. Disadvantage: They will not show up in the Project Manager, so it will slow down the workflow every time you need to find a file.
Solution 3: Create a project for each target platform. Disadvantage: Every time you add new units or change common project settings you have to (remember to) apply it to all projects.
Update: As suggested in the Malcom Groves video, placing all the business logic in a package will remove the disadvantage from Solution 3. So I consider solution 3 as the best approach.
Challenge 2: How to connect the different device forms to the (same) business logic?
Possible solution: Create a "Helper" class that contains all the code you would normally have in the form unit.
Update: This "Helper class" is actually what the MVVM calls a ViewModel. What I need seem to be a MVVM framework that can support the databinding. I have made another question about that.
Any input and suggestions about best practice are welcome.
For challenge 1:
You can conditionally link in your FireMonkey form resources depending on the compile target:
{$R *.Windows.fmx MSWINDOWS}
{$R *.Macintosh.fmx _MACOS}
etc.
This is excatly what the XE7 Multiview designer does, but I see nothing against using this mechanism to link whole form files conditionally in to your executable. Of course you might also want to ifdef the corresponding units in your project file.
For challenge 2: Just use some form of Model View Controler logic. So your platform dependant forms will talk to a platform independant controler.
I'm developing enterprise web application which is using JSF with Eclipse IDE. But i'n not experienced at JSF web application architect, just not familiar with name classes ,projects,packages,web pages, template pages etc.. , is it possible to name packages like following:
CompanyName.systemName.controller (there would be controllers in it )
CompanyName.systemName.Model (there would be managed beans and other things in it )
even how to choose best structure for my project(mean Architecture of folders,classes,packages,web pages, template pages etc). if anyone has an idea ? i'd be glad if have sample project.
thanks
Those are fine package names. Some people like to group packages by purpose:
org.mycompany.myapp.controller
org.mycompany.myapp.dao
org.mycompany.myapp.service
etc...
For larger applications, I like to group them by feature:
org.mycompany.myapp.billing
org.mycompany.myapp.signup
org.mycompany.myapp.webservices
etc...
As for folder structure, a good Maven archetype can be very helpful. Here's a web page that gives a good walkthrough of setting up a few types of JSF projects using Maven archetypes: http://www.javaserverfaces.org/get-started
If you look from architecture point of view, your JSF application should mirror very much like any other well architected Java-Web application.
For packaging I like to break first by functionality (like core, gui) and then by business unit level.
Something like:
com.comp.core.db.beans
com.comp.extension.ui.extension //If my application is going to give extension point for others to implement, extend the functionality.
com.comp.core.ui.controller
On a similar note pages, config files can be broken into separate logical units.
I need some advices or experiences in integrating custom annotations for Doctrine generated entities, but I also want to keep native Doctrine annotations so that they can be somehow registered together.
I have succesfully integrated Doctrine in my ZF application and tested it.
Now I want to have some validations inside my entites. I don't want to write any code in my entities or modify setters. I googled for suggestions and there are some libraries that do the job. Those libraries also provide the ability to return Doctrine entities objects as array (toArray()).
I tried to integrate one of those called Spiffy Library (https://github.com/SpiffyJr/Spiffy). Homepage http://www.spiffyjr.me/.
I followed instructions on that page to include it in my project but no luck. Any help on these would be so appreciated.
Guess I didn't setup correctly AnnotationReader. However I did AnnotationRegistry-ed some of files from Spiffy library (spiffy\Doctrine\Annotations\Validators).
Also gave Spiffy Abstract library my entity manager from ZF registry.
I can also paste some of my code here if neccessary.
Thnaks in advance.
I really like the Ria Services approach, and I see Lightswitch as the next higher level of abstraction, but my scenario is this:
I need to be able to define a Lighswitch app without having to rely on the designer and tedious click-throughs. If I have access to the API that the designer uses, then I can automate application generation, I can parameterize it and apply custome logic for generating custom variations of the same application type, I can even wrap it within a DSL. As a programmer, I want to levarge Lightswitch for developing applications by meta-programming.
I'm a programmer. Whilest I can use the "Write Code" dropdown to insert code blocks into the Application, ApplicationDataService, EntityObject and ScreenObject classes, I would like the ability to define entites, screens, relationships and queries through code / markup / a DSL.
Obviously Lightswitch meta-programs this when I use the designer, but I would like to do it myself. What I would like to accomplish is to create a lightswitch app - without having to click through a tool or designer. In Lightswitch, the pieces are obviously there (the designer leverages them), but they are not exposed as a public API. being a plugin for visual studio, perhaps there is a VSIX API extension I can leverage for automating Lightswitch? Show me some code.
The LS team have not yet released any official API information. As you may know however, all of various data/query/screen definitions exist in the ApplicationDefinition.lsml file, located in the LS project's "Data" folder.
I would hope that API information will be made available once the RTM has been released.
Yann