I am a total newbie on Prism. I have been getting to understand a lot from questions on SO and from various Blogs. I am using latest build – V2
I want some explanations on things that may be pretty easy things for you guys but it’s just not getting into my brains (small one for that).
Instead of doing it all right the first time , for which I have spent more than two weeks looking at various blogs, webcast …., I thought to start a project and learn. The amount of information on those hundreds of sites was overwhelming and difficult to digest.
Currently my project is setup like this
Shell -- Menu Module- ViewModel - - -> Menu Service -- -- > Menu Repository --- Data
All are in different assembly
MyShell --- MenuModule ---MyServices -- Myrepository
Shell is required to reference modules ( thought I am sure I can add it using string) later on .
ViewModel has a reference to View - Can live with it for now
View Model requires to use menu service and menu service uses repository
All are built with constructor injection. I have it working now by having module reference MyService and Myrepository projects and then registering types at module level.
But this does not feel good. I don’t want to hard reference any projects. If we are referencing projects why use IoC. In MenuModule.cs ( which is in the root of module) I can register views with unity container
I think I am getting a feel that the answer to this one may lie in the first question
Is Configuration file the answer/
Should I use configuration file for
true decoupling?
If (somehow) we can
register types from code, should we
register types at module level ( I
don’t want to have hard reference to projects)
I need to know the
Interfaces in advance so do you
recommend separate assembly for just
Interfaces?
Bear with me if the questions sound real stupid
You don't need a configuration file for true decoupling. All you need is to register your types in your shell's bootstrapper. I usually break up my projects and refs like this.
Contract Assembly
(Contains only a few simple types and interfaces)
Referenced by:
Shell
Modules
Shell
(Contains concrete implementations of interfaces defined in Contract assembly)
Referenced by:
No one
Modules
(Declares dependencies on interfaces defined in Contracts assembly, for instance IMenuRegistry)
Referenced by:
No one (I use a Directory Module to search for modules in a directory)
Here's a sample project I put together. In this sample I reference the module from the shell for simplicity's sake, but you can remove that reference and use a directory module catalog to load the compiled module at runtime:
http://dl.getdropbox.com/u/376992/CAGMenus.zip
Hope this helps,
Anderson
You're definitely on the right track. Use the configuration file to register your types, and put the interfaces in a separate assembly.
Related
Apologies if this sounds like a silly question. I'm not very experienced with how things are linked/bundled/assembled under the hood.
Before I begin, I'd like to say that I've tried reading documentation (such as https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing) to find the answer, but was unable to.
If I have a Xamarin.Forms solution and I reference a .Net Standard project:
Question 1: Does all the code from this project get compiled and included into the app such that it may be disassembled later, or is it only code from classes that I actually make use of that gets included?
Bit more elaboration:
For example, I may have a School class that expects an IStudent (inject via DI), and a Student class that implements IStudent. Both of these exist in the .Net Standard project that I reference in the Xamarin.Forms project. However, if I only actually make use of the Student class (by registering it with type IStudent in my IoC container), will the code from School get included in the built app as well?
Question 2: If all the code from the project does get included, is there a way to forcefully specify which classes to include/exclude by way of some configuration setting, attributes, 3rd-party library, or something else?
As far as i know everything in the NETStandard project get compiled and shipped with the app.
If you want to remove unused code from compiled assemblies you have to use the linker.
To link everything, you have to select "Sdk and User Assemblies".
The linker tries to dont strip away mthods and fields you are using, but often is too aggressive (for example, methods referenced only by reflection will be stripped).
Luckily there are few methods where you can fine-tune the linker behaviour and make it work. Some link to elaborate on:
Linker in iOS and Android
https://learn.microsoft.com/en-us/xamarin/ios/deploy-test/linker
https://learn.microsoft.com/en-us/xamarin/android/deploy-test/linker
Official doc about the linker config:
https://learn.microsoft.com/en-us/xamarin/cross-platform/deploy-test/linker
Useful blogposts:
https://xamarinhelp.com/xamarin-linker/
https://medium.com/#harrycblum/reduce-your-xamarin-app-size-with-linking-26247edc87f6
I've got two questions here. The first one is just specific and another one is more general, but is a source of the first one.
So, my specific problem: I want to use Encryption (actually, Hashing) algorithms with using System.Security.Cryptography namespace (for instance, SHA256Managed class).
I found out that (happily) Xamarin has implemented those in System.dll.
But it is not portable and obviously can not be used from Core application directly.
But I've also found another great project -- PclContrib -- which allows you to do that. But, unfortunately, they don't have the implementation for Touch and Android. (However, that still works great for Desktop (Web) and Windows Phone, plus, still can be included into Core (as it uses portable project)).
Anyway, to solve that nicely, I've decided to create some base class for the encryption methods and then override core methods which require the custom dll (for any custom system).
The way I did it (at least, trying to do) was:
Defining virtual method in Core App base class:
public virtual IEncryptionProvider CreateEncryptionProvider()
Overriding Core App class in Touch project with overriding CreateEncryptionProvider (which creates an instance of TouchEncryptionProvider class instance).
Core:
public class App : MvxApplication
Touch:
public class AppTouch : App
Launching it in Touch setup.cs:
protected override Cirrious.MvvmCross.ViewModels.IMvxApplication CreateApp (
{
return new AppTouch();
}
But, that does not work for me. On startup I've got this exception message in log:
"Exception masked KeyNotFoundException: Could not find view for Mynamespace.Etc.LoginViewModel", which works fine when I do new App() instead. I am not sure if that message shows actual problem (as before it was saying the same even that was a problem with some third-party dll, unrelated to views at all). But speaking shortly, that's just a primitive inheritance of App : MvxApplication, but placed not in Core but Touch project.
So, does it requeire some more custom initialization for such situations or do I miss something else?
And, actually, more general question is how should I build such Multiplatform approaches? Actually, now I've got similar problem with HttpUtility.UrlEncode, which I would want to use in my Core project.
What is the MvvmCross "philosophy" to handle such situations?
Thank you.
For the 'viewmodel not found' problem, this is caused because mvvmcross by default only looks for viewmodels in the Assembly containing your app.
If you want it to look in other assemblies, override ViewModelAssemblies in Setup.cs - see how this done in, for example, MvvmCross - structuring shared View Models and Views
For general multplatform approach, please read questions and answers like:
Platform-specific IoC in MVVMCross
Instantiation of ViewModels and Service classes
Please also remember you don't have to use PCLs - if you prefer to use file-linking between multiple platform-specific core projects, then you can of course use this approach.
Finally, please also try to ask one question per question - I find it makes stackoverflow work better for users and with search engines too. If you need to link questions, then you can just add a hyperlink reference - stackoverflow then marks them as related.
Hi i want to know what is meant by modules in a project??how they are classified and how many modules we can have in a project?can anyone explain with simple examples??What modules we can have in a typical online shopping website?
In .net context I believe one can draw 2 meanings not sure what specific you are looking for.
One is modular programming by following design principles like "Separation of concerns", "Single Responsibility", "loose coupling". This means divide you code into classes based on these principles and further group these classes again based on these principles into modules.
In ASP.NET or C# or in general we create class library projects and use them across the entire project. Like all the logging functionality is put in some classes and these classes are include in an class library project which can be called "Logging module". Whenever you need logging in any of the project you can include this module and use the functionality.
Some examples:
Web module for HTTP requests ( The WebApp)
Repository and Data access Layer modules. (DAL code)
Models module containing all the business entities.
WebService modules for integrating with other apps.
Logging for debugging and problem identification
Infrastructure/Utility modules for utility like functionalities and
application configuration.
Business logic modules.
Transaction gateway module.
Other way to define module in .net is they are PE files and I believe they have extension .netmodule which contain Metadata but they do not contain the assembly manifest. To use a module you have to create a PE file with the necessary assembly manifest.
Create a module:
csc /t:module ufo.cs
Create assembly using the module:
csc /t:library /addmodule:ufo.netmodule /out:airvehicles.dll helicopter.cs
Above 2 commands are from this link
The module is an external code that you plugin on your site and runs in order to do some actions.
(source: codeguru.com)
We make and use modules to have the ability to share the actions of the module with others with out giving the source code, and vice versa, we use modules from other that we do not have access to the source code. Or we can simple use module for have the ability so simplify our code and remove it easy if we do not need it.
We can have as modules as we like, but each module place extra overhead on our code - after all is need to make more thinks there.
More about modules: http://www.codeguru.com/csharp/.net/net_asp/article.php/c19389/HTTP-Handlers-and-HTTP-Modules-in-ASPNET.htm
How to create module: http://support.microsoft.com/kb/307996
I'm starting with a Symfony2 project. I know the framework basics but I have a question:
Where is the right place to pot those helper classes I create for help or for the business logic?
Max's answer is correct. However I question the path he recommends for your code.
The following classes and files have specific emplacements:
Service Container Extensions (belong in) DependencyInjection/
from http://symfony.com/doc/current/cookbook/bundles/best_practices.html
That says your Services should be placed in a folder called 'DependencyInjection', not 'Services'. In full, it should be src/Foo/BarBundle/DependencyInjection
I say this as someone that had the former and has just finished moving them all to the latter (!)
What #Adam says is wrong, you have to store your Dependency Injection Extensions in DependecyInjection directory, not the services itself. In the documentation says that you can store your (custom) business logic classes in any place you like.
http://symfony.com/doc/current/best_practices/business-logic.html
The best way to keep the business logic is create service to handle all the logic. So it will be in:
src/Foo/BarBundle/Service
and you need to call the service in the services.yml.
I recently did some small work on an existing Symfony2 project. As described by answer from Tuong Le, I created my Helper classes under the Helper directory of the bundle and class name with Helper suffix i.e. the helper class is located at:
src/MyBundle/Helper/MyUtilHelper.php
I can use MyUtilHelper class in my bundle without calling the service container i.e. I didn't need to call.
$container->get('my_util');
I don't really know whether there is some special config. in my setup; someone already got it setup and I was just adding new functionality.
You can create the custom classes under your Bundle, such as under a folder Helper/..
However, to use those helper in your code, you'll need to define those Helper(s) in your service description file (such as services.xml)... Then you can use $container->get('your_helper')->
According to official documentation - in particular - Symfony Best Practices - you should store your services in Utils folder under the src. I belive, that this is correct way regardless of whether you want or don't wont to make the functionality provided by services of your bundle available to other parts of application via Service Container. Furthermore, you can store helper classes in any place you consider suitable. Concerning #Adam Knowles and #PachinSV answers - they are not quite right because they do not answer your question - "Where is the right place to pot those helper classes I create for help or for the business logic?" or "Where to store classes which I want to register and use via Service Container" - but not where to put bundle Extension class - which main purpose is to provide information about configuration which should be automatically loaded from your bundle to apps Service Container during the process of booting the Kernel.
I am starting with a project in Spring-mvc which basically is made up of 3 parts
1) Frontend
2) Backend (admin)
3) Web service
What would be best way to organize these parts so that I can reuse the domain and DAO layer objects wherever I can and at the same time keep the packages separate (so as to avoid class names such as FrontendCategoryController and BackendCategoryController in the same package) ?
Also would it be a good idea to have common config and the pom.xml file for all these parts ?
As of now I have started with the project structure generated by maven as per the webapp archetype
Edit:
One way I am thinking of doing this is -
myapp
-- src
-- main
--java
--resources
-- backend
--java
-- resources
-- webservice
-- java
-- resources
in all java directories, the package names will be same
Would this be a correct approach
Thanks
First of all, depicted approach that misuses Maven directory structure looks really bad.
You say that you want to avoid long class names such as FrontendCategoryController and BackendCategoryController. It looks like your design violates "Package by feature, not layer" rule. You can create separate packages for your subapplications, so that long class names wouldn't be needed. Common classes used by all subapplications can be placed in yet another package.
Alternative approach would be to create separate Maven projects for different subapplications, but it looks like you don't want it.