We have an ERP solution, which had lot of modules. As a product company we are having several clients.
The source control is maintained in TFS.
Now we customization for reach clients, what is the best way to manage the source code?
Truly I believe this depends on the language the application is built with:
MVC
In general, hopefully the business logic of all the applications is remaining the same, in that way the only differences would be in the view of each new instance. To manage these different views I would create sub-folders for each product. But once again this is very generic as we don't know much about the current infrastructure.
Edit
Generally Speaking the branching stragey described here will work for most cases: https://stackoverflow.com/a/20878555/5268586. For your application, if you are changing core logic located inside your application consider extending a base class for each client and overriding it's functionality to handle the new clients calculations.
i.e.
you have a class/file called CalcEngine
your client want to change some calculations, so make a new class Client1CalcEngine that will implement all of CalcEngine and override the one method/function. These customer focused classes can then be bundled in your normal branches, as the implementation logic will decypther which to use.
Related
I want to ask this because I want to know developer perspective about developing from scratch mobile games.
Let's say the project is already going to start its development.
I am already aware of the specification of the project example.
Logic, Browser/devices to support, IDE to be used.
What should be the first thing to do.
Create the UI/UX designs for all devices with no functionality
and after the designs are finalized then integrate functionality
Create functionality logic then do design
Do design and functionality together
which of these will save much more time.
please share your experiences about this development and how to make out of it
so that failure of delivering the project will be at its minimum errors
Every of these aproaches may work, however I will tell you about my experience.
I did a lot of different projects using points you provide in the question, but for me the easiest and most successful approach was logic first, design second.
How to start using this approach?
Think about use case at first. For example, user should be able to register in the game.
Implement database structure(if needed). For example, create table 'Users'.
Implement data access logic. For example, write code that saves a username and a password.
Create service layer with use case's (business) logic implementation . For example, you can write saveUser method.
Create a simple(ugly) UI that allows you to feel the use case and to test it.
Pay guru designer to create clean design. For example, a design of the registration page.
Сontinue with step 1.
Advantages?
Allows to create really working MVP with ease.
UI manipulates only real and dynamic data.
Allows you to build foundation first.
I'm studying Prism and need to create a small demo app. I have some design questions. The differences between attitudes might be small, but I need to apply the practices to a large scale project later, so I'm trying to think ahead.
Assuming the classical DB related scenario - I need to get a list of employees and a double click on a list item gets extra information for that employee: Should the data access project be a module, or is a project accessed via repository pattern a better solution? What about large scale project, when the DB is more than one table and provides, say, information about employees, sales, companies etc.?
I'm currently considering to use the DataAccess module as a stand alone module, and have defined its interface in the Infrastructure project as well as its return type (EmployeeInformation). This means that both my DataAccess module and my application have to reference the Infrastructure project. Is this a good way to go?
I'm accessing said DataAccess module using ServiceLocator (MEF) from my application. Should the ServiceLocator be accessed by parts of the application, or is it meant to be used in the initialization section only?
Thanks.
A module is needed and makes sense when it contains ine part of the application that can live on it's own. This can be parts of an application the only several people need or are allowed to use, e.g. the user management module only administrators are allowed to access. But your data access layer is not that kind of isolated functionality that usually goes into a module. It is better placed in a common assembly the real modules can use. The problem here is that all modules depend on this DAL assembly, so have the task of updating your DAL in mind when designing your application (downward compatibility).
Usually there is no problem to have types that are broadly used reside in a common assembly. But this is not the infrastructure assembly. Infrastructure, as the word implies, provides services to have the modules work together. Your common types should go into something like YourNamespace.Types or YourNamespace.Client.Base or ...
This is a topic in many arguments and still unclear (at least from my point of view). Purists of Dependency Injection say it should only be used during initialization. Pragmatists are using the ServiceLocator all over their application.
I’m developing a part of an application, named A. The application I want to plug my DLL into, called application B is in vb 6, and my code is in vb.net. (Application B will in time be converted to vb.net) My main question i, how is the best way for me to organize my code (application A)?
I want to split application A into layers (Service, Business, Data access), so it will be easy to integrate application A into B when B is converted to vb.net. I also want to learn about all the topics like layered architecture, patterns, inversion of dependency, entity framework and so on. Although my application (A) is small I want to organize my code in the best way.
The application I’m working with (A) is using web services for authenticating users and for sending schema to an organization. The user of application B is selecting a menu point in application B and then some functions in my application A is called.
In application A I have an auto generated schema class from an xsd schema. I fill this schema object with data and serialize the object to a memory string (is it a good solution to use memory string, I don’t have to save the data yet), wrap the xml inside a CDATA block and return the CDATA block as a string and assign the CDATA block to a string property of a web service.
I am also using Entity framework for database communication (to learn how this is done for the future work with application B). I have two entities in my .edmx, User and Payer.
I also want to use the repository pattern (is this a good choice?) to make a façade between the DAL and the BLL.
My application has functions for GeneratingSchema (filling the schema object with data), GetSchemaContent, GetSchemaInformation, GenerateCDATABlock, WriteToTextFile, MemoryStreamToString, EncryptData and some functions that uses web services, like SendShema, AuthenticateUser, GetAvalibelServises and so on.
I’m not sure where I should put it all?
I think I have to have some Interfaces like IRepository, ISchema (contract for the auto generated schema class, how can I do this?) ICryptoManager, IFileManager and so on, and classes that implements the interfaces.
My DAL will be the Entity framework. And I want a repository façade in my BLL (IRepository, UserRepository, PayerRepository) and classes for management (like the classes I have mention above) holding functions like WriteToFile, EncryptData …..
Is this a good solution (do I need a service layer, all my GUI is in application B) and how can I organize my layers, interfaces, classes an functions in Visual Studio?
Thanks in advance.
This is one heck of a question, thought I might try to chip away at a few parts for you so there's less for the next guy to answer...
For application B (VB6) to call application/assemblies A, I'm going to assume you're exposing the relevant parts of App A as COM Components, using ComVisibleAttributes and similar, much like described in this artcle. I only know of one other way (WCF over COM) but I've never tried it myself.
Splitting your solution(s) into various tiers and layers is a very subjective/debatable topic, and will always come down to a combination of personal preference, business requirements, time available, etc. However, regardless of the depth of your tiers and layers, it is good to understand the how and the why.
To get you started, here's a couple articles:
Wikipedia's general overview on "Multitier Architectures"
MSDN's very own "Building an N-Tier Application in .Net"
Inversion of Control is also a very good pattern to get into right now, with ever increasing (and brilliant!) resources becoming available to the .Net platform, it's definitely worth infesting some time to learn.
Although I haven't explored the full extent of IoC, I do love dependency injection(a type of IoC if I understand correctly though people seem to muddle the IoC/DI terms quite a lot). My personal preference for DI right now is the open source Ninject project, which has plenty of resources online and a reasonable wiki section talking you through the various aspects.
There are many more takes on DI and IoC, so I don't want to even attempt to provide you a comprehensive list for fear of being flamed for missing out somebody's favourite. Just have a search, see which you like the look of and have a play with it. Make sure to try a couple if you have the time.
Again, the Repository Pattern - often complemented well by the Unit of Work Pattern are also great topics to mull over for hours. I've seen a lot of good examples out on the inter-webs, and as many bad examples. My only advice here is to try it for yourself... see what works for you, develop a version of the patterns that suits you best and try to keep things consistent for maintainability.
For organising all these tiers and layers in VS, I recommend trying to keep all your independent tiers/layers in their own Solution Folders (r-click the Solution, Add New Solution Folder), or in some cases (larger projects) there own solutions and preferably an automated build service to update dependent projects with up to date assemblies as required. Again, a broad subject and totally down to personal preference. Just keep an eye out when designing your application for potential upcoming Circular References.
So, I'm afraid that doesn't even slightly answer your question, but hopefully provides you with some resources to check out and a few hours of reading.
Good luck!
My team is in the process of designing a domain model which will hide various different data sources behind a unified repository abstraction. One of the main drivers for this approach is the very high probability that these data sources will undergo significant change in the near future and we don't want to be re-writing business logic when this happens. One data source will be our membership database which was originally implemented using the default ASP.Net Membership Provider. The membership provider is tied to the System.Web.Security namespace but we have a design guideline requiring that our domain model layer is not dependent upon System.Web (or any other implementation/environment dependency) as it will be consumed in different environments - nor do we want our websites directly communicating with databases.
I am considering what would be a good approach to reconciling the MembershipProvider approach with our abstracted n-tier architecture. My initial feeling is that we could create a "DomainMembershipProvider" which interacts with the domain model and then implement objects in the model which deal with the repository and handle validation/business logic. The repository would then implement data access using our (as-yet undecided) ORM/data access tool.
Are there are any glaring holes in this approach - I haven't worked closely with the MembershipProvider class so may well be missing something. Alternatively, is there an approach that you think will better serve the requirements I described above?
Thanks in advance for your thoughts and advice.
Regards,
Zac
It's been 6 months since the question was asked and no one seems to have been able to provide an answer so I thought I'd explain the solution we eventually chose.
Basically, we have decided not to use any implementation of the MembershipProvider - instead we use our own custom Membership Service sitting atop a repository. It was important for us to maintain the existing aspnet_Membership database so our repository has basically duplicated the built-in SQLMembershipProvider functionality (at least, the aspects we need of it) - initially via Linq-to-SQL but now we're transitioning to NHibernate. The plan is to replace the membership database in a year or so when all of our websites are upgraded to use the new model.
It was possible to use a custom membership provider but in the end it became apparent that it was simpler, more consistent, and more maintainable to use a custom implementation. We are still using the built-in forms authentication functionality for verifying that a user is logged in and for redirecting users who try to access secure areas of our site without first being authenticated - but we have overridden the functionality that is tied to the profile provider.
Ultimately, our feelings on this are that while the membership provider is a powerful and easy-to-use tool within ASP.Net, if it doesn't fit with the wider approach used in your application, it is worth considering an alternative approach.
Interesting, thanks for posting your final solution. I am in a similar situation, but writing a custom Membershipprovider. I don't know where to put the provider because it needs access to the DB as well as System.Web namespace. It seems like it's the one class that violates this whole separation of concerns design.
Having used some PHP frameworks such as Codeigniter and Kohana for some smaller sites, I'm starting to wonder if MVC is still applicable for larger projects and, if so, what precautions need to be taken to maintain clean clode. What practices do the larger sites use in order to prevent this? Does Amazon's or Flickr's code use MVC or some variant of it? Is there a guide that, given a certain problem, shows you how best to implement MVC for large projects?
-- Tangent --
On a current project using Kohana, I started to question what role my models should have. Often times, a model can only describe a small part of an object that I'm trying to build. I.e., need an object for a User, so I extract my user from the Users table using my Users_Model. But each user also has several items in their inventory, so I need to also use the Users_Inventory_Model. But, each inventory item also has other tables associated with it, and so on, until I find that building up a single User in my controller has required me to access several models. Now, imagine doing this in many different controllers and suddenly I find myself with messy and redundant code and very fat controllers.
This led me to think that maybe I should have libraries which handle most of the grunt work. That way, I could have a Users library and let it load all of my pertinent user data and run most of the logic such as updating, deleting, etc. Is this the way most MVC projects evolve? Letting libraries do most of the interaction with the models, while the controllers call the libraries and prepare the data for the views? Anyway, this is just one of the questions I've had about MVC, which I haven't been able to find an answer to online.
In fact, it's for big projects where all these MVPs and MVCs really shine. All software design patterns are "created" (besides establishing common vocabulary) to deal with complexity of software. Thus, used properly, MVC will be of great help to you in big projects.
Contrast with small apps, which can be hacked together with mouse-only approach, but are a nightmare to support since there's no proper separation nor they're SOLID enough.