I have used Symfony 1.x forever now and am starting to get a handle on 2.x. What a daunting task converting from 1.x to 2.x is as I'm sure many of you already know.
I have a question about the Model for non database stuff.
in 1.x you had /lib/model/doctrine/abc.class.php and /lib/model/doctrine/abcTable.class.php. All your non-database model functions went in abc.class.php and all your database stuff went in abcTable.class.php
I want to add a couple of GD functions to make thumbnails of uploaded images but I'm pretty sure in the MVC conventions they are not suppose to go in the controller file. But I can't find a model folder or any place that even says model for non database stuff anywhere in the Symfony2 docs.
Can someone please let me know what the new convention for "Model" for non database elements and custom functions that use to go in lib/model folder are now located (or called) in Symfony2?
There is not really a convention for this type of stuff per say. You can add the methods to the model, or you can create a separate class that consumes a model and does all of the work that needs to be done.
I personally would create a service that handles the process. Takes the input from the controller, creates the model and the the thumbnails. I would not put the gd functions into my model classes.
Related
I am new to Xamarin. I have done a couple of smaller projects (2-3 pages, one table). I have a new project that is a great candidate for a shell app. It will have 20 pages, will consume data from a transactional database (cloud hosted) but also have an offline datastore (SQLite). Right now, I just want to get the local version up and running. The template for Shell App generates an IDataService and a MockDataStore. That is a great place to start - but how do I have more than one table? I am a little confused how I would use that. What I would love to see is a template generated shell app that just adds another table (and corresponding list,detail views along with view models. For example, the simple "todo" sample but add a contact table to assign todo tasks to would be perfect. Thanks in advance for your help.
I hope this helps others new to Xamarin. When starting a new project and choosing anything other than the "blank template", the template generates a model (Item) and a services folder containing an Interface (IDataStore) and a MockDataStore. Being new to XAML in general, I spent a lot of time working on getting the UI to look like what I wanted it, learning about Shell navigation and similar topics. Finally it was time to include the data part of my project. Where I got stuck was trying to make sense of the boilerplate code. My understanding of DependencyService was for platform specific code (e.g. Android, iOS) and NOT data service dependency. Further, the templated code is a typed interface (IDataStore). The solution was fundamental - all that interface does is insure CRUD operations are available in whatever you use in a datastore. For me, simply changing IDataStore to not be typed as an Item, solved everything. It allowed me to keep the database layer abstracted away. In my little project, I completed my "MockDataStore" adding additional CRUD operations until I was ready for my real data operations. NOTE: if you generate the WEB API project from the template, it will make more sense - you can flip between your MockDataStore and actual data store.
What is the best practice for using the Cache Component in Symfony 3?
Simple example:
If I call getCategoryById (In Repository) from different places (Controller, FormType, Twig function, Listener, ...), how can I verify that the data is cached or not?
Problem:
I can't call Cache Component in Repository and I don't want to write and duplicate the same code in every place ( isHint ... ).
Question:
So what is the best practice? Create an intermediate cache service between all components and the Repository?
Thank you very much :)
I'm creating a template for our server-side codegen implementation, but I ran into an issue for a feature request...
The developers who are going to use the generated base want the following pattern (the generator is based on the dotnetcore):
Controllers
v{apiVersion}
{endpoint}ApiController : Controller, I{endpoint}Api
Interfaces
v{apiVersion}
I{endpoint}Api
I{endpoint}DataProvider
DataProviders
-v{apiVersion}
-{endpoint}DataProvider : I{endpoint}DataProvider
Both interfaces are the same, describing the endpoints. The DataProvider implementation will allow us to use DI to hot-swap the actual data provider/business logic layer during runtime.
The generated ApiControllers will refer to the IDataProviders, and use the actual implementation (the currently active one, that is). For that we're going to use dotnetcore's built-in dependency injection system.
However I can't seem to find a way to have the operations generator output to three different folders, based on the template. It will all end up jumbled in a single folder, and I will need to manually move them.
Is there a way to solve these requirements, or should I solve it all the time manually?
Looking at the Single page application beta in the MVC 4 I don't see how I can use my legacy domain objects as the model. It seems to require that the model use the entity framework to using DbDataController to get the data etc.
I do not understand the entity framework so I am probably missing something.
How can I use my legacy domain (with it's own DAL) in the SPA of MVC 4?
This was answered by somebody else in an ASP.NET forum.
You won't be able to use anything other than EF if you want to use some of these RAD tools. However, SPA builds on top of MVC, so you should be able to build your own version rather easily. The important components would be building a DataController on top of ApiController and a js consumer for the service provided by your DataController. It's possible that if you were to format your models in the same format as the EF output (I think it's just OData) you could use upshot.js, as well and only have to implement a DataController to format your domain models.
I will add the following after working with it for a couple of days that you could, theoretically, use it if the following are handled/fixed by you and future versions of the SPA.
You can create a controller that inherits from System.Web.Http.Data.DataController (and maybe even ApiController). The objects it returns then must just have a property decorated with the System.ComponentModel.DataAnnotations.Key() attribute. I can get the views to work fine but some of the more advance features, like grouping, I am having problems with.
Readonly property will not be returned I guess because of a problem with the current JSON serializer used. Should be fixed.
Of course the entire object will be serialized which can be very problematic if your domain objects are complex with child objects. Especially if some of those objects have serialization issues of their own.
Related to the complex serialization the current JSON serializer cannot handle circular references in the domain objects referenced.
I have also run into problems getting update/deletes/inserts being posted back when using my own Controller that inherits from System.Web.Http.Data.DataController (the examples use DBDataController).
We're currently migrating our ASP Intranet to .NET and we started to develop this Intranet in one ASP.NET website. This, however, raised some problems regarding Visual Studio (performance, compile-time, ...).
Because our Intranet basically exists of modules, we want to seperate our project in subprojects in Visual Studio (each module is a subproject).
This raises also some problems because the modules have references to each other.
Module X uses Module Y and vice versa... (circular dependencies).
What's the best way to develop such an Intranet?
I'll will give an example because it's difficult to explain.
We have a module to maintain our employees. Each employee has different documents (a contract, documents created by the employee, ...).
All documents inside our Intranet our maintained by a document module.
The employee-module needs to reference the document-module.
What if in the future I need to reference the employee-module in the document-module?
What's the best way to solve this?
It sounds to me like you have two problems.
First you need to break the business orientated functionality of the system down into cohesive parts; in terms of Object Orientated design there's a few principles which you should be using to guide your thinking:
Common Reuse Principle
Common Closure Principle
The idea is that things which are closely related, to the extent that 'if one needs to be changed, they all are likely to need to be changed'.
Single Responsibility Principle
Don't try to have a component do to much.
I think you also need to look at you dependency structure more closely - as soon as you start getting circular references it's probably a sign that you haven't broken the various "things" apart correctly. Maybe you need to understand the problem domain more? It's a common problem - well, not so much a problem as simply a part of designing complex systems.
Once you get this sorted out it will make the second part much easier: system architecture and design.
Luckily there's already a lot of existing material on plugins, try searching by tag, e.g:
https://stackoverflow.com/questions/tagged/plugins+.net
https://stackoverflow.com/questions/tagged/plugins+architecture
Edit:
Assets is defined in a different module than employees. But the Assets-class defines a property 'AssignedTo' which is of the type 'Employee'. I've been breaking my head how to disconnect these two
There two parts to this, and you might want to look at using both:
Using a Common Layer containing simple data structures that all parts of the system can share.
Using Interfaces.
Common Layer / POCO's
POCO stands for "Plain Old CLR Objects", the idea is that POCO's are a simple data structures that you can use for exchanging information between layers - or in your case between modules that need to remain loosely Coupled. POCO's don't contain any business logic. Treat them like you'd treat the String or DateTime types.
So rather than referencing each other, the Asset and Employee classes reference the POCO's.
The idea is to define these in a common assembly that the rest of your application / modules can reference. The assembly which defines these needs to be devoid of unwanted dependencies - which should be easy enough.
Interfaces
This is pretty much the same, but instead of referring to a concrete object (like a POCO) you refer to an interface. These interfaces would be defined in a similar fashion to the POCO's described above (common assembly, no dependencies).
You'd then use a Factory to go and load up the concrete object at runtime. This is basically Dependency Inversion.
So rather than referencing each other, the Asset and Employee classes reference the interfaces, and concrete implementations are instantiated at runtime.
This article might be of assistance for both of the options above: An Introduction to Dependency Inversion
Edit:
I've got the following method GetAsset( int assetID ); In this method, the property asset.AssignedTo (type IAssignable) is filled in. How can I assign this properly?
This depends on where the logic sits, and how you want to architect things.
If you have a Business Logic (BL) Layer - which is mainly a comprehensive Domain Model (DM) (of which both Asset and Employee were members), then it's likely Assets and Members would know about each other, and when you did a call to populate the Asset you'd probably get the appropriate Employee data as well. In this case the BL / DM is asking for the data - not isolated Asset and Member classes.
In this case your "modules" would be another layer that was built on top of the BL / DM described above.
I variation on this is that inside GetAsset() you only get asset data, and atsome point after that you get the employee data separately. No matter how loosely you couple things there is going to have to be some point at which you define the connection between Asset and Employee, even if it's just in data.
This suggests some sort of Register Pattern, a place where "connections" are defined, and anytime you deal with a type which is 'IAssignable' you know you need to check the register for any possible assignments.
I would look into creating interfaces for your plug-ins that way you will be able to add new modules, and as long as they follow the interface specifications your projects will be able to call them without explicitly knowing anything about them.
We use this to create plug-ins for our application. Each plugin in encapsulated in user control that implements a specific interface, then we add new modules whenever we want, and because they are user controls we can store the path to the control in the database, and use load control to load them, and we use the interface to manipulate them, the page that loads them doesn't need to know anything about what they do.