I was going through Unity 2.0 to check if it has an effective use in our new application. My application is a Windows Forms application and uses a traditional bar menu (at the top), currently.
My UIs (Windows Forms) more or less support Dependency Injection pattern since they all work with a class (Presentation Model Class) supplied to them via the constructor. The form then binds to the properties of the supplied P Model class and calls methods on the P Model class to perform its duties. Pretty simple and straightforward.
How P Model reacts to the UI actions and responds to them by co-ordinating with the Domain Class (Business Logic/Model) is irrelevant here and thus not mentioned.
The object creation sequence to show up one UI from menu then goes like this -
Create Business Model instance
Create Presentation Model instance with Business Model instance passed to P Model constructor.
Create UI instance with Presentation Model instance passed to UI constructor.
My present solution:
To show an UI in the method above from my menu I would have to refer all assemblies (Business, PModel, UI) from my Menu class. Considering I have split the modules into a number of physical assemblies, that would be a dificult task to add references to about 60 different assemblies. Also the approach is not very scalable since I would certainly need to release more modules and with this approach I would have to change the source code every time I release a new module.
So primarily to avoid the reference of so many assemblies from my Menu class (assembly) I did as below -
Stored all the dependency described above in a database table (SQL Server), e.g.
ModuleShortCode | BModelAssembly | BModelFullTypeName | PModelAssembly | PModelFullTypeName | UIAssembly | UIFullTypeName
Now used a static class named "Launcher" with a method "Launch" as below -
Launcher.Launch("Discount");
Launcher.Launch("Customers");
The Launcher internally uses data from the dependency table and uses Activator.CreateInstance() to create each of the objects and uses the instance as constructor parameter to the next object being created, till the UI is built. The UI is then shown as a modal dialog. The code inside Launcher is somewhat like -
Form frm = ResolveForm("Discount");
frm.ShowDialog();`
The ResolveForm does the trick of building the chain of objects.
Can Unity help me here?
Now when I did that I did not have enough information on Unity and now that I have studied Unity I think I have been doing more or less the same thing. So I tried to replace my code with Unity.
However, as soon as I started I hit a block. If I try to resolve UI forms in my Menu as
Form customers = myUnityContainer.Resolve<Customers>();
or
Form customers = myUnityContainer.Resolve(typeof(Customers));
Then either way, I need to refer to my UI assembly from my Menu assembly since the target Type "Customers" need to be known for Unity to resolve it. So I am back to same place since I would have to refer all UI assemblies from the Menu assembly. I understand that with Unity I would have to refer fewer assemblies (only UI assemblies) but those references are needed which defeats my objectives below -
Create the chain of objects dynamically without any assembly reference from Menu assembly. This is to avoid Menu source code changing every time I release a new module. My Menu also is built dynamically from a table.
Be able to supply new modules just by supplying the new assemblies and inserting the new Dependency row in the table by a database patch.
At this stage, I have a feeling that I have to do it the way I was doing, i.e. Activator.CreateInstance() to fulfil all my objectives. I need to verify whether the community thinks the same way as me or have a better suggestion to solve the problem.
The post is really long and I sincerely thank you if you come til this point. Waiting for your valuable suggestions.
Rajarshi
As I can see from this code
Form customers = myUnityContainer.Resolve<Customers>();
all your code need to know about the customer - is that it's a Form class. So if you use xml configuration for unity you can do the following:
<type type="Form" mapTo="Customer" name="Customer">
</type>
And then you'll be able to resolve it like this:
Form customers = myUnityContainer.Resolve<Form>("Customer");
and there is no need to refference your UI assembly. Offcourse it should be presented in the bin directory or GAC. In this case if you'll develop new Assembly - all you need is to change config and put in in bin or gac.
If you want to make unity configuration from db then you'll have to add referrence to your ui, becouse you'll have to call Register("Customer").
Related
I'm using Visual Studio 2013 and ASP.Net MVC 5. I've created a bunch of views for my models and then I've changed them. I want to run scaffolding on some models and create some views automatically and then change the automatically-generated views. Is there another way other than re-naming some files or creating another solution and copying stuff?
Yes, you can re-scaffold by scaffolding the same model again, using the same model class and controller names as before. Your existing controller and views will be replaced.
Details:
Right click on your project or controller folder,
Add ... New Scaffolded Item,
MVC 5 Controller with views using Entity Framework,
Add
Choose your model and data class,
And ensure your controller name is the same as the one to replace.
I use version control - GIT to do it quickly and safely. I use Git Extensions (http://code.google.com/p/gitextensions/) user interface for git.
Have your code commited before re-scaffolding. Then re-scaffold the views, and go to staging (the button Commit in Git Extensions). It shows all changes that re-scaffold made and colors the new and deleted code lines. From there you can stage only the selected new lines, that changed in controller. After staging selected lines, reset the unstaged other changes.
There you have it! Your already modified code with new scaffolded parts. Do any edits and testing necessary and commit.
This is a new answer to an old question. It's somewhat similar to the existing answers, but I think different enough and easy enough to be of value.
1) Save the existing project/solution to version control just as good practice.
2) When re-scaffolding, use a different controller name which will create a controller class and it's 5 attendant views, but it won't overwrite anything that exists, preserving all your existing work.
3) Extract the appropriate methods from the re-scaffolded controller. Bindings for create/edit will likely change when the model changes, so capture those. Then delete the re-scaffolded controller.
4) That leaves the views in place to copy and paste the appropriate UI code for any new or redefined model properties. Once all the code needed has been copied, simply delete the re-scaffolded views.
It was a great question because we often have to change a model, and it's nice to have all the basic UI stuff automatically created for us.
i have used the repo pattern in my web forms application in the following way
UI Layer:
it contains the code behind files in which the controls are being binded and user actions like insert update etc are catered for
the UI Layer calls the
Repository Layer:
it contains the repository classes inheriting the GenericRepo:IGeneric
and the
Data Layer:
it contains the EF generated domain classes
the layers are strict for the time being that is the UI layer calls the Repo layer and it in turns call the data layer to fetch the data.
Problem:
now the problem im facing is that if for example i need a list of products on the Products.aspx page i need to do some thing like
IProductRepo pr = new ProductRepo();
IList<Products> lstProducts = pr.GetAll();
i dont want to add the reference of Data Layer to the UI layer in order to access the domain entities i.e generated by the EF
what are my options? please guide me to the right path
regards.
In my opinion you're missing a layer. I would built it like this:
UI |
----- |
**Domain** | Domain classes
----- |
DAL (Repository) |
This way your logic is in a separate layer and your DAL is completely hidden from your logic and domain model.
Another way you could solve this problem is by using Dependency Injection. That way you can define some interfaces and only keep references to interfaces. With a dependency container you can ten tie those references to real types.
My preferred DI container is for example Ninject
In web application, i am created one new project in that i added class library, like business layer, datalayer, but when i am accessing the business class in datalayer, class object is created but, when i am accessing the fileds of that class like example :
EmpBL objEmb= new EmpBL();
objEmb is not coming in intellesence, even i am not accessing the fileds of business class can you help me out please.
right click on your data layer project, select Add Reference and select Project tab - then add reference to your .Business project.
However, you can now have circular references, i.e. you can't reference each other. And normally, Business Objects project references Data Access project, not the other way around. Although any architecture is possible, and sometimes BOL project is just storage classes, and they don't know anything about DAL - a third project brings them together. Not sure about your exact architecture.
I'm doing some refactoring and am trying to reuse my genertated entity models. My application has a few assemblies, one being my outward facing public types (API) and one containing implementations of providers (such as the log).
I'd like to split the generation of the entities and models so that the entities will be in the API assembly and the container will be in the implementation assembly. Is this possible?
Is possible. This is how I did it.
Assembly A
Database.EDMX
Models.TT
Models.cs
Assembly B
Database.EDMX (Added as a Link to the real file in Assembly A)
EntityContainer.TT
EntityContainer.cs
That's how everything is laid out. These are the rough steps:
Right click on the EDMX in A (public API assembly) and Add Code Generation File
Adds a TT to the project. Called it Models, as it will contain the models only.
Edited the TT and removed code generation for entity containers
In assembly B (internal implementations) added Database.EDMA as a link
Opened in assembly B, right click and Add Code Generation File
Adds a TT to project B. Called it EntityContainer as it will contain that only.
Edited TT to do the following
Removed entity creation steps
Changed the path to Database.EDMX to a relative path pointing at the original copy in A
Added a using for my models
Hopefully this will all compile and work correctly (I'm still far from getting everything compiled and tested). Looks good so far.
Additional change:
In my entity container TT, I had to modify the definition of the EscapeEndTypeName to the following:
string EscapeEndTypeName(AssociationType association, int index,
CodeGenerationTools code)
{
EntityType entity = association.AssociationEndMembers[index]
.GetEntityType();
return code.CreateFullName(
code.EscapeNamespace(association.NamespaceName), code.Escape(entity));
}
I'm using association.NamespaceName as it contains the correct namespace from the other assembly.
I don't know the answer, but I think that your question is essentially equivalent to "Is it possible to cause a T4 template in one project to emit code into a different project?" If you can do that, then you can do what you want. Note, though, that this is substantially easier in EF 4.
So I think you might get useful feedback if you asked that question directly.
I want to put context-sensitive, dynamic command options on my asp.net pages.
I tried coding my own command structure but it's not very good, and I'm sure there must be a framework for doing this somewhere I can re-use?
Example:
I have a detailsview for some database object, I want to code in the object class what commands are available, based on the state of the object. I then want a UI object I can place on the webform that will pass commands back to the object when user clicks them, or jump to a different link (e.g. when additional parameters are available).
e.g. form might look like this
Product Details
Name: XXXX product
Price: $1.00
Qty: 1
Commands:
> Edit
> New Stock
> Mark as obsolete
So the commands at the bottom would have very little UI code and pass actions back to the object. For example the New Stock command would jump to a new page to ask for a quantity.
I don't know of the framework, but you could create something yourself. Let's say you are using MVP pattern, and assuming that this is a CRUD application, you could tell each view what type of object it is related to, then annotate you object with operations that are available. Then Presenter could call Service to perform the operation. You could name your methods using some convention so that you can wire it up in a Service. It is a lot of work, and unless you have 100s of views it is not worth while. I am building app that is about that size, and I am in process of creating GenericMVP framework, that would make wiring a breeze.